idnits 2.17.1 draft-carpenter-anima-grasp-bulk-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 date (September 12, 2017) is 2417 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-00 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-04 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-04 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-04 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: March 16, 2018 B. Liu 6 Huawei Technologies Co., Ltd 7 September 12, 2017 9 Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol 10 (GRASP) 11 draft-carpenter-anima-grasp-bulk-00 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 March 16, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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. Datagram Transport Layer . . . . . . . . . . . . . . . . . . 7 57 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 8 58 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 10.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 The document [I-D.liu-anima-grasp-distribution] discusses how 71 information may be distributed within the secure Autonomic Networking 72 Infrastructure (ANI) [I-D.ietf-anima-reference-model]. Specifically, 73 it describes using the Synchronization and Flood Synchronization 74 mechanisms of the GeneRic Autonomic Signaling Protocol (GRASP) 75 [I-D.ietf-anima-grasp] for this purpose. However, those mechanisms 76 are limited to distributing GRASP Objective Options contained in 77 messages that cannot exceed the GRASP maximum message size of 2048 78 bytes. 80 There are scenarios in autonomic networks where this restriction is a 81 problem. One example is the distribution of network policy in 82 lengthy formats such as YANG or JSON. Another case might be an 83 Autonomic Service Agent (ASA) uploading a log file to the Network 84 Operations Center (NOC). A third case might be a supervisory system 85 downloading a software upgrade to an autonomic node. 87 Naturally, an existing solution such as a secure file transfer 88 protocol or secure HTTP might be used for this. Other management 89 protocols such as syslog [RFC5424] or NETCONF [RFC6241] might also be 90 used for related purposes, or might be mapped directly over GRASP. 91 The present document, however, applies to any scenario where it is 92 preferable to re-use the autonomic networking infrastructure itself 93 rather than an additional mechanism, but there is a need to transfer 94 a large amount of data. The basic model is to use the GRASP 95 Negotiation process to transfer and acknowledge multiple blocks of 96 data in successive negotiation steps. 98 NOTE: This is an early draft of a solution. As the specification 99 becomes more mature, the authors expect it to become precise enough 100 to be placed on the standards track. 102 2. General Method for Bulk Transfer 104 As for any GRASP operation, the two participants are considered to be 105 Autonomic Service Agents (ASAs) and they communicate using a specific 106 GRASP Objective Option, containing its own name, some flag bits, a 107 loop count, and a value. In bulk transfer, we can model the ASA 108 acting as the source of the transfer as a download server, and the 109 destination as a download client. Compared to a normal GRASP 110 negotiation, the communication pattern is slightly asymmetric: 112 1. The client first discovers the server by the GRASP discovery 113 mechanism (M_DISCOVERY and M_RESPONSE messages). 115 2. The client then sends a GRASP negotiation request (M_REQ_NEG 116 message). The value of the objective expresses the requested 117 item (e.g., a file name - see the next section for a detailed 118 example). 120 3. The server replies with a negotiation step (M_NEGOTIATE message). 121 The value of the objective is the first section of the requested 122 item (e.g., the first block of the requested file as a raw byte 123 string). 125 4. The client replies with a negotiation step (M_NEGOTIATE message). 126 The value of the objective is a simple acknowledgement (e.g., the 127 text string 'ACK'). 129 The last two steps repeat until the transfer is complete. The server 130 signals the end by transferring an empty byte string as the final 131 value. In this case the client responds with a normal end to the 132 negotiation (M_END message with an O_ACCEPT option). 134 Errors of any kind are handled with the normal GRASP mechanisms, in 135 particular by an M_END message with an O_DECLINE option in either 136 direction. 138 The block size must be chosen such that each step does not exceed the 139 GRASP message size limit of 2048 bits. 141 This approach is safe since each block must be positively 142 acknowledged, and data transfer errors will be detected by TCP. If a 143 future variant of GRASP runs over UDP, the mandatory UDP checksum for 144 IPv6 will detect such errors. The method does not currently specify 145 retransmission for failed blocks, so a failed transfer will need to 146 be restarted. In an enterprise network with low bit error rates, 147 this is not considered a serious issue. 149 An observant reader will notice that the GRASP loop count mechanism, 150 intended to terminate endless negotiations, will cause a problem for 151 large transfers. For this reason, both the client and server must 152 artificially increment the loop count by 1 before each negotiation 153 step. 155 If network load is a concern, the data rate can be limited by 156 inserting a delay before each negotiation step, with the GRASP 157 timeout set accordingly. Either the server or the client, or both, 158 could insert such a delay. Also, either side could use the GRASP 159 Confirm Waiting (M_WAIT) message to slow the other side down. 161 The description above concerns bulk download from a server 162 (responding ASA) to a client (requesting ASA). The data transfer 163 could also be in the opposite (upload) direction with minor 164 modifications to the procedure: the client would send the data blocks 165 and the server would send acknowledgements. 167 3. Example for File Transfer 169 This example describes a client ASA requesting a file download from a 170 server ASA. 172 Firstly we define a GRASP objective informally: 174 ["411:mvFile", 3, 6, value] 176 The formal CDDL definition [I-D.ietf-cbor-cddl] is: 178 mvfile-objective = ["411:mvFile", objective-flags, loop-count, value] 180 objective-flags = ; as in the GRASP specification 181 loop-count = ; as in the GRASP specification 182 value = any 184 The objective-flags field is set to indicate negotiation. 186 Dry run mode must not be used. 188 The loop-count is set to a suitable value to limit the scope of 189 discovery. A suggested default value is 6. 191 The value takes the following forms: 193 o In the initial request from the client, a UTF-8 string containing 194 the requested file name (with file path if appropriate). 196 o In negotiation steps from the server, a byte string containing at 197 most 1024 bytes. However: 199 * If the file does not exist, the first negotiation step will 200 return an M_END, O_DECLINE response. 202 * After sending the last block, the next and final negotiation 203 step will send an empty byte string as the value. 205 o In negotiation steps from the client, the value is the UTF-8 206 string 'ACK'. 208 Note that the block size of 1024 is chosen to guarantee not only that 209 each GRASP message is below the size limit, but also that only one 210 TCP data packet will be needed, even on an IPv6 network with a 211 minimum link MTU. 213 We now present outline pseudocode for the client and the server ASA. 214 The API documented in [I-D.liu-anima-grasp-api] is used in a 215 simplified way, and error handling is not shown in detail. 217 Pseudo code for client ASA (request and receive a file): 219 requested_obj = objective('411:mvFile') 220 locator = discover(requested_obj) 221 requested_obj.value = 'etc/test.pdf' 222 received_obj = request_negotiate(requested_obj, locator) 223 if error_code == declined: 224 #no such file 225 exit 227 file = open(requested_obj.value) 228 file.write(received_obj.value) #write to file 229 eof = False 230 while not eof: 231 received_obj.value = 'ACK' 232 received_obj.loop_count = received_obj.loop_count + 1 233 received_obj = negotiate_step(received_obj) 234 if received_obj.value == null: 235 end_negotiate(True) 236 file.close() 237 eof = True 238 else: 239 file.write(received_obj.value) #write to file 241 #file received 242 exit 243 Pseudo code for server ASA (await request and send a file): 245 supported_obj = objective('411:mvFile') 246 requested_obj = listen_negotiate(supported_obj) 247 file = open(requested_obj.value) #open the source file 248 if no such file: 249 end_negotiate(False) #decline negotiation 250 exit 252 eof = False 253 while not eof: 254 chunk = file.read(1024) #next block of file 255 requested_obj.value = chunk 256 requested_obj.loop_count = requested_obj.loop_count + 1 257 requested_obj = negotiate_step(requested_obj) 258 if chunk == null: 259 file.close() 260 eof = True 261 end_negotiate(True) 262 exit 263 if requested_obj.value != 'ACK': 264 #unexpected reply... 266 4. Datagram Transport Layer 268 The above description and example assume that GRASP is implemented 269 over a reliable transport layer such as TCP, such that lost or 270 corrupted messages need not be considered. In the event that GRASP 271 is implemented over an unreliable transport layer such as UDP, it 272 would be necessary to add a block number to both the data block and 273 acknowledgement objectives, so that missing blocks can be 274 retransmitted, or duplicate blocks can be ignored. For example, the 275 objective in Section 3 would become: 277 mvfile-objective = ["411:mvFile", objective-flags, loop-count, value] 279 objective-flags = ; as in the GRASP specification 280 loop-count = ; as in the GRASP specification 281 value = [block-number, any] 282 block-number = uint 284 It would also be necessary for the transport layer to detect data 285 errors, for example by enabling UDP checksums. 287 5. Maximum Transmission Unit 289 In an IPv6 environment, a minimal MTU of 1280 bytes can be assumed, 290 and assuming that high throughput is not a requirement, bulk 291 transfers can be designed to match that MTU. However, there are 292 environments where the underlying physical MTU is much smaller. For 293 example, on an IEEE 802.15.4 network it may be less than 100 bytes 294 [RFC4944]. In such a case, a bulk transfer solution has several 295 choices: 297 1. Accept the overhead of an adaptation layer, and therefore assume 298 a network-layer MTU of 1280 bytes. 300 2. Attempt to determine the actual MTU available without lower-layer 301 fragmentation. 303 3. Attempt to determine a message size that provides optimum 304 performance. 306 TBD: further discussion? 308 6. Other Considerations 310 TBD - discussion of specific use cases? 312 TBD - discussion of user space API for bulk transfer? 314 7. Security Considerations 316 All GRASP transactions are secured by the mandatory security 317 substrate required by [I-D.ietf-anima-grasp]. No additional security 318 issues are created by the application of GRASP described in this 319 document. 321 8. IANA Considerations 323 This document makes no request of the IANA. 325 9. Acknowledgements 327 TBD. 329 10. References 330 10.1. Normative References 332 [I-D.ietf-anima-grasp] 333 Bormann, C., Carpenter, B., and B. Liu, "A Generic 334 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 335 grasp-15 (work in progress), July 2017. 337 [I-D.ietf-cbor-cddl] 338 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 339 definition language (CDDL): a notational convention to 340 express CBOR data structures", draft-ietf-cbor-cddl-00 341 (work in progress), July 2017. 343 10.2. Informative References 345 [I-D.ietf-anima-reference-model] 346 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 347 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 348 Reference Model for Autonomic Networking", draft-ietf- 349 anima-reference-model-04 (work in progress), July 2017. 351 [I-D.liu-anima-grasp-api] 352 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 353 Autonomic Signaling Protocol Application Program Interface 354 (GRASP API)", draft-liu-anima-grasp-api-04 (work in 355 progress), June 2017. 357 [I-D.liu-anima-grasp-distribution] 358 Liu, B. and S. Jiang, "Information Distribution over 359 GRASP", draft-liu-anima-grasp-distribution-04 (work in 360 progress), May 2017. 362 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 363 "Transmission of IPv6 Packets over IEEE 802.15.4 364 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 365 . 367 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 368 DOI 10.17487/RFC5424, March 2009, 369 . 371 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 372 and A. Bierman, Ed., "Network Configuration Protocol 373 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 374 . 376 Appendix A. Change log [RFC Editor: Please remove] 378 draft-carpenter-anima-grasp-bulk-00, 2017-09-12: 380 Initial version. 382 Authors' Addresses 384 Brian Carpenter 385 Department of Computer Science 386 University of Auckland 387 PB 92019 388 Auckland 1142 389 New Zealand 391 Email: brian.e.carpenter@gmail.com 393 Sheng Jiang 394 Huawei Technologies Co., Ltd 395 Q14, Huawei Campus, No.156 Beiqing Road 396 Hai-Dian District, Beijing, 100095 397 P.R. China 399 Email: jiangsheng@huawei.com 401 Bing Liu 402 Huawei Technologies Co., Ltd 403 Q14, Huawei Campus 404 No.156 Beiqing Road 405 Hai-Dian District, Beijing 100095 406 P.R. China 408 Email: leo.liubing@huawei.com