idnits 2.17.1 draft-carpenter-anima-grasp-bulk-01.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 date (March 3, 2018) is 2239 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 == Outdated reference: A later version (-09) exists of draft-carpenter-anima-asa-guidelines-03 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-06 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: September 4, 2018 B. Liu 6 Huawei Technologies Co., Ltd 7 March 3, 2018 9 Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol 10 (GRASP) 11 draft-carpenter-anima-grasp-bulk-01 13 Abstract 15 This document describes how bulk data may be transferred between 16 Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol 17 (GRASP). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 4, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. General Method for Bulk Transfer . . . . . . . . . . . . . . 3 55 3. Example for File Transfer . . . . . . . . . . . . . . . . . . 4 56 4. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 8 58 6. Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 11.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The document [I-D.liu-anima-grasp-distribution] discusses how 72 information may be distributed within the secure Autonomic Networking 73 Infrastructure (ANI) [I-D.ietf-anima-reference-model]. Specifically, 74 it describes using the Synchronization and Flood Synchronization 75 mechanisms of the GeneRic Autonomic Signaling Protocol (GRASP) 76 [I-D.ietf-anima-grasp] for this purpose. However, those mechanisms 77 are limited to distributing GRASP Objective Options contained in 78 messages that cannot exceed the GRASP maximum message size of 2048 79 bytes. 81 There are scenarios in autonomic networks where this restriction is a 82 problem. One example is the distribution of network policy in 83 lengthy formats such as YANG or JSON. Another case might be an 84 Autonomic Service Agent (ASA) uploading a log file to the Network 85 Operations Center (NOC). A third case might be a supervisory system 86 downloading a software upgrade to an autonomic node. A related case 87 might be installing the code of a new or updated ASA to a target node 88 (see the discussion of ASA life cycles in 89 [I-D.carpenter-anima-asa-guidelines]). 91 Naturally, an existing solution such as a secure file transfer 92 protocol or secure HTTP might be used for this. Other management 93 protocols such as syslog [RFC5424] or NETCONF [RFC6241] might also be 94 used for related purposes, or might be mapped directly over GRASP. 95 The present document, however, applies to any scenario where it is 96 preferable to re-use the autonomic networking infrastructure itself 97 to transfer a significant amount of data, rather than install and 98 configure an additional mechanism. The basic model is to use the 99 GRASP Negotiation process to transfer and acknowledge multiple blocks 100 of data in successive negotiation steps. 102 The emphasis is placed on simplicity rather than efficiency, high 103 throughput, or advanced functionality. For example, if a transfer 104 gets out of step or data packets are lost, the strategy is to abort 105 the transfer and try again. In an enterprise network with low bit 106 error rates, and with GRASP running over TCP, this is not considered 107 a serious issue. Clearly, a more sophisticated approach could be 108 designed but if the application requires that, existing protocols 109 could be used, as indicated in the preceding paragraph. 111 NOTE: This is an early draft of a solution. As the specification 112 becomes more mature, the authors expect it to become precise enough 113 to be placed on the standards track. 115 2. General Method for Bulk Transfer 117 As for any GRASP operation, the two participants are considered to be 118 Autonomic Service Agents (ASAs) and they communicate using a specific 119 GRASP Objective Option, containing its own name, some flag bits, a 120 loop count, and a value. In bulk transfer, we can model the ASA 121 acting as the source of the transfer as a download server, and the 122 destination as a download client. No changes or extensions are 123 required to GRASP itself, but compared to a normal GRASP negotiation, 124 the communication pattern is slightly asymmetric: 126 1. The client first discovers the server by the GRASP discovery 127 mechanism (M_DISCOVERY and M_RESPONSE messages). 129 2. The client then sends a GRASP negotiation request (M_REQ_NEG 130 message). The value of the objective expresses the requested 131 item (e.g., a file name - see the next section for a detailed 132 example). 134 3. The server replies with a negotiation step (M_NEGOTIATE message). 135 The value of the objective is the first section of the requested 136 item (e.g., the first block of the requested file as a raw byte 137 string). 139 4. The client replies with a negotiation step (M_NEGOTIATE message). 140 The value of the objective is a simple acknowledgement (e.g., the 141 text string 'ACK'). 143 The last two steps repeat until the transfer is complete. The server 144 signals the end by transferring an empty byte string as the final 145 value. In this case the client responds with a normal end to the 146 negotiation (M_END message with an O_ACCEPT option). 148 Errors of any kind are handled with the normal GRASP mechanisms, in 149 particular by an M_END message with an O_DECLINE option in either 150 direction. 152 The block size must be chosen such that each step does not exceed the 153 GRASP message size limit of 2048 bits. 155 This approach is safe since each block must be positively 156 acknowledged, and data transfer errors will be detected by TCP. If a 157 future variant of GRASP runs over UDP, the mandatory UDP checksum for 158 IPv6 will detect such errors. The method does not specify 159 retransmission for failed blocks, so a failed transfer will need to 160 be restarted. 162 An observant reader will notice that the GRASP loop count mechanism, 163 intended to terminate endless negotiations, will cause a problem for 164 large transfers. For this reason, both the client and server must 165 artificially increment the loop count by 1 before each negotiation 166 step. 168 If network load is a concern, the data rate can be limited by 169 inserting a delay before each negotiation step, with the GRASP 170 timeout set accordingly. Either the server or the client, or both, 171 could insert such a delay. Also, either side could use the GRASP 172 Confirm Waiting (M_WAIT) message to slow the other side down. 174 The description above concerns bulk download from a server 175 (responding ASA) to a client (requesting ASA). The data transfer 176 could also be in the opposite (upload) direction with minor 177 modifications to the procedure: the client would send the file name 178 and the data blocks, and the server would send acknowledgements. 180 3. Example for File Transfer 182 This example describes a client ASA requesting a file download from a 183 server ASA. 185 Firstly we define a GRASP objective informally: 187 ["411:mvFile", 3, 6, value] 189 The formal CDDL definition [I-D.ietf-cbor-cddl] is: 191 mvfile-objective = ["411:mvFile", objective-flags, loop-count, value] 193 objective-flags = ; as in the GRASP specification 194 loop-count = ; as in the GRASP specification 195 value = any 197 The objective-flags field is set to indicate negotiation. 199 Dry run mode must not be used. 201 The loop-count is set to a suitable value to limit the scope of 202 discovery. A suggested default value is 6. 204 The value takes the following forms: 206 o In the initial request from the client, a UTF-8 string containing 207 the requested file name (with file path if appropriate). 209 o In negotiation steps from the server, a byte string containing at 210 most 1024 bytes. However: 212 * If the file does not exist, the first negotiation step will 213 return an M_END, O_DECLINE response. 215 * After sending the last block, the next and final negotiation 216 step will send an empty byte string as the value. 218 o In negotiation steps from the client, the value is the UTF-8 219 string 'ACK'. 221 Note that the block size of 1024 is chosen to guarantee not only that 222 each GRASP message is below the size limit, but also that only one 223 TCP data packet will be needed, even on an IPv6 network with a 224 minimum link MTU. 226 We now present outline pseudocode for the client and the server ASA. 227 The API documented in [I-D.liu-anima-grasp-api] is used in a 228 simplified way, and error handling is not shown in detail. 230 Pseudo code for client ASA (request and receive a file): 232 requested_obj = objective('411:mvFile') 233 locator = discover(requested_obj) 234 requested_obj.value = 'etc/test.pdf' 235 received_obj = request_negotiate(requested_obj, locator) 236 if error_code == declined: 237 #no such file 238 exit 240 file = open(requested_obj.value) 241 file.write(received_obj.value) #write to file 242 eof = False 243 while not eof: 244 received_obj.value = 'ACK' 245 received_obj.loop_count = received_obj.loop_count + 1 246 received_obj = negotiate_step(received_obj) 247 if received_obj.value == null: 248 end_negotiate(True) 249 file.close() 250 eof = True 251 else: 252 file.write(received_obj.value) #write to file 254 #file received 255 exit 256 Pseudo code for server ASA (await request and send a file): 258 supported_obj = objective('411:mvFile') 259 requested_obj = listen_negotiate(supported_obj) 260 file = open(requested_obj.value) #open the source file 261 if no such file: 262 end_negotiate(False) #decline negotiation 263 exit 265 eof = False 266 while not eof: 267 chunk = file.read(1024) #next block of file 268 requested_obj.value = chunk 269 requested_obj.loop_count = requested_obj.loop_count + 1 270 requested_obj = negotiate_step(requested_obj) 271 if chunk == null: 272 file.close() 273 eof = True 274 end_negotiate(True) 275 exit 276 if requested_obj.value != 'ACK': 277 #unexpected reply... 279 4. Loss Detection 281 The above description and example assume that GRASP is implemented 282 over a reliable transport layer such as TCP, such that lost or 283 corrupted messages are not likely. Rarely, an error might be 284 detected via a missing ACK, in which case the transfer would be 285 aborted and restarted. In the event that GRASP is implemented over 286 an unreliable transport layer such as UDP, it would be possible to 287 add a block number to both the data block and acknowledgement 288 objectives, so that missing blocks can be retransmitted, or duplicate 289 blocks can be ignored. For example, the objective in Section 3 would 290 become: 292 mvfile-objective = ["411:mvFile", objective-flags, loop-count, value] 294 objective-flags = ; as in the GRASP specification 295 loop-count = ; as in the GRASP specification 296 value = [block-number, any] 297 block-number = uint 299 It would also be necessary for the transport layer to detect data 300 errors, for example by enabling UDP checksums. 302 5. Maximum Transmission Unit 304 In an IPv6 environment, a minimal MTU of 1280 bytes can be assumed, 305 and assuming that high throughput is not a requirement, bulk 306 transfers can be designed to match that MTU. However, there are 307 environments where the underlying physical MTU is much smaller. For 308 example, on an IEEE 802.15.4 network it may be less than 100 bytes 309 [RFC4944]. In such a case, a bulk transfer solution has several 310 choices: 312 1. Accept the overhead of an adaptation layer, and therefore assume 313 a network-layer MTU of 1280 bytes. 315 2. Attempt to determine the actual MTU available without lower-layer 316 fragmentation. 318 3. Attempt to determine a message size that provides optimum 319 performance. 321 TBD: further discussion? 323 6. Pipelining 325 The above description and example descibe a simple handshake model 326 where each block is acknowledged before the next block is sent. For 327 the scenarios discussed in Section 1, this should be acceptable. 328 Therefore we do not suggest adding a pipelining or windowing 329 mechanism. If high throughput is required, a conventional file 330 transfer protocol should be used. 332 7. Other Considerations 334 If multiple transfers are requested simultaneously, each one will 335 proceed as a separate GRASP negotiation session. The ASA acting as 336 the server must be coded accordingly, like any ASA that needs to 337 handle simultaneous sessions [I-D.carpenter-anima-asa-guidelines]. 339 TBD - discussion of specific use cases? 341 TBD - discussion of user space API for bulk transfer? 343 8. Security Considerations 345 All GRASP transactions are secured by the mandatory security 346 substrate required by [I-D.ietf-anima-grasp]. No additional security 347 issues are created by the application of GRASP described in this 348 document. 350 9. IANA Considerations 352 This document makes no request of the IANA. 354 10. Acknowledgements 356 Thanks to Joel Halpern and other members of the ANIMA WG. 358 11. References 360 11.1. Normative References 362 [I-D.ietf-anima-grasp] 363 Bormann, C., Carpenter, B., and B. Liu, "A Generic 364 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 365 grasp-15 (work in progress), July 2017. 367 [I-D.ietf-cbor-cddl] 368 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 369 definition language (CDDL): a notational convention to 370 express CBOR data structures", draft-ietf-cbor-cddl-02 371 (work in progress), February 2018. 373 11.2. Informative References 375 [I-D.carpenter-anima-asa-guidelines] 376 Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre, 377 "Guidelines for Autonomic Service Agents", draft- 378 carpenter-anima-asa-guidelines-03 (work in progress), 379 October 2017. 381 [I-D.ietf-anima-reference-model] 382 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 383 and J. Nobre, "A Reference Model for Autonomic 384 Networking", draft-ietf-anima-reference-model-06 (work in 385 progress), February 2018. 387 [I-D.liu-anima-grasp-api] 388 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 389 Autonomic Signaling Protocol Application Program Interface 390 (GRASP API)", draft-liu-anima-grasp-api-06 (work in 391 progress), November 2017. 393 [I-D.liu-anima-grasp-distribution] 394 Liu, B., Jiang, S., Xiao, X., Hecker, A., and Z. 395 Despotovic, "Information Distribution in Autonomic 396 Networking", draft-liu-anima-grasp-distribution-05 (work 397 in progress), February 2018. 399 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 400 "Transmission of IPv6 Packets over IEEE 802.15.4 401 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 402 . 404 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 405 DOI 10.17487/RFC5424, March 2009, 406 . 408 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 409 and A. Bierman, Ed., "Network Configuration Protocol 410 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 411 . 413 Appendix A. Change log [RFC Editor: Please remove] 415 draft-carpenter-anima-grasp-bulk-01, 2018-03-03: 417 Updates after IETF100 discussion. 419 draft-carpenter-anima-grasp-bulk-00, 2017-09-12: 421 Initial version. 423 Authors' Addresses 425 Brian Carpenter 426 Department of Computer Science 427 University of Auckland 428 PB 92019 429 Auckland 1142 430 New Zealand 432 Email: brian.e.carpenter@gmail.com 434 Sheng Jiang 435 Huawei Technologies Co., Ltd 436 Q14, Huawei Campus, No.156 Beiqing Road 437 Hai-Dian District, Beijing, 100095 438 P.R. China 440 Email: jiangsheng@huawei.com 441 Bing Liu 442 Huawei Technologies Co., Ltd 443 Q14, Huawei Campus 444 No.156 Beiqing Road 445 Hai-Dian District, Beijing 100095 446 P.R. China 448 Email: leo.liubing@huawei.com