idnits 2.17.1 draft-jhjung-core-sensor-streaming-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 (October 22, 2018) is 2006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Joong H. Jung 2 Intended status: Standards Track Dong K. Choi 3 Expires: April 2019 Seok J. Koh 4 Kyungpook National University 5 October 22, 2018 7 CoAP Sensor Streaming Using Buffer Control 8 draft-jhjung-core-sensor-streaming-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on April 22, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 As the Internet of Things (IoT) technology grows with the development 51 of wireless communication and sensors, many people are interested in 52 Constrained Application Protocol (CoAP), which is the representative 53 protocol of the IoT. In addition, attempts have been made to apply 54 CoAP to sensors that support existing real-time streaming services. 55 However, the CoAP is not suitable for services to support streaming 56 services such as smart band and CCTV. To overcome this drawback, 57 there is an extension called CoAP Observe, but streaming services 58 using CoAP Observe imposes a load on the server, which is not 59 suitable for environments where low power devices act as servers, 60 such as data transfer between sensors and gateways. In this 61 specification, we are considering the situation in which the sensor 62 acts as a server, and in this environment, we define one mechanism to 63 provide efficient streaming service. 65 Table of Contents 67 1. Introduction ................................................ 2 68 1.1. Background ............................................. 2 69 1.2. Terminology ............................................ 2 70 1.3. Overview of the proposed scheme ........................ 2 71 2. The Buffer-Control Option ................................... 7 72 2.1. Buffer-Control Option meaning in request ............... 7 73 2.2. Buffer-Control Option meaning in a notification ........ 8 74 3. Subject Side Operation ...................................... 8 75 3.1. Register ............................................... 8 76 3.2. Caching ................................................ 8 77 3.3. Change the buffer size ................................. 9 78 3.4. Unregister ............................................. 9 79 4. Observer Side Operation ..................................... 9 80 4.1. Register ............................................... 9 81 4.2. Buffer Control ......................................... 9 82 4.3. Reordering ............................................. 9 83 5. Security consideration ..................................... 10 84 6. IANA Considerations ........................................ 10 85 7. References ................................................. 10 86 7.1. Normative References .................................. 10 87 Authors' Addresses ............................................ 10 89 1. Introduction 91 1.1. Background 93 The Constrained Application Protocol (CoAP) is the most widely used 94 protocol in constrained environments such as sensor networks. Along 95 with the growth of the Internet of Things services (IoT), a variety 96 of real-time streaming services (e.g., CCTV) are provided by using 97 the CoAP. 99 However, how to effectively use CoAP for real-time streaming services 100 is still under study. Since the CoAP has been basically designed to 101 support RESTful services, it may not be suitable to use for streaming 102 services. To overcome these drawbacks, the CoAP Observe Extension 103 [RFC7641] has been studied. This extension supports the well-known 104 CoAP observer design pattern. But, In case that a sensor acts as a 105 server, the extension needs to be enhanced, because a lot of loads 106 may be given to the server. 108 In this document, the CoAP Observe extension [RFC7641] will be 109 extended to support real-time streaming services so as to deal with 110 packet error appropriately and to reduce the load on the sensor. To 111 achieve this goal, a new option "Buffer-Control" of the CoAP Observe 112 extension is additionally defined. This option is used to control the 113 buffer in sensor for real-time streaming service. 115 1.2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 1.3. Overview of the proposed scheme 125 The main purpose of this document is to propose a new mechanism for 126 real-time streaming. This mechanism will be effective when the sensor 127 device periodically transmits the sensing data to the gateway, such 128 as CCTV or smart band. In this document, a sensor device acts as a 129 CoAP server, and a gateway acts as a client that requests data 130 transmission to the sensor. Our description will be based on the 131 terms defined in RFC 7641. The entity that transmits data 132 periodically is called the subject, and the entity that receives the 133 data is called the observer. 135 The receiver who wants streaming service MUST go through the 136 registration procedure. The receiver sends a POST message to request 137 the creation of a streaming service to the subject. Various 138 parameters for the streaming service (e.g., authentication 139 information, the interval between messages, or the buffer size) are 140 transmitted with the POST message. The subject receiving the message 141 checks the parameters and returns a 4.xx error code with an error 142 message if it cannot create a resource for streaming. When the 143 resource is successfully created, the subject returns the URL of the 144 generated resource. The observer then issues a GET request with the 145 Observe Option to the received URL, and if the resource 146 representative is normally received, the registration procedure for 147 the streaming service is completed. Figure 1 shows an example flow of 148 registration process. 150 +---------+ +----------+ 151 | Subject | | Observer | 152 +---------+ +----------+ 153 | POST /Streaming | 154 | Token: 0x71 | 155 | Buffer-Control: 0 | 156 | Payload: Parameters | 157 |<-------------------------------+ 158 | | 159 | 2.01 CREATED | 160 | Token: 0x71 | 161 | Payload: Stream1 | 162 +------------------------------->| 163 | | 164 | GET /Streaming/stream1 | 165 | Token: 0x71 | 166 | Observe: 0 | 167 |Payload: Resource Representative| 168 |<-------------------------------+ 169 | | 170 | 2.05 CONTENT | 171 | Token: 0x72 | 172 | Observe: 0 | 173 | Buffer-Control: 7 | 174 |Payload: Resource Representative| 175 +------------------------------->| 176 | | 177 | 2.05 CONTENT | 178 | Token: 0x72 | 179 | Observe: 1 | 180 | Buffer-Control: 6 | 181 |Payload: Resource Representative| 182 +------------------------------->| 183 | | 185 Figure 1: Streaming Service Request 187 When the registration process is completed, the subject periodically 188 transmits the sensing information to the observer, until it receives 189 a DELETE message or until the buffer is full. The subject transmits 190 only non-confirmable messages and stores them in the buffer. If an 191 observer receives the message, it performs reordering with Observe 192 option value as a sequence number. Then, it transmits a PUT message 193 to clear the buffer to avoid that the sensor buffer is full. A PUT 194 message is transmitted for each number of messages of 'sensor buffer 195 size / 2 - 1'. For instance, if the buffer size is 8, when the 196 observer receives 3 messages from the subject, it transmits a PUT 197 message. Therefore, two PUT messages can be transmitted before the 198 buffer is full, and even if one PUT message is lost, the transmission 199 of the message continues without block time. The PUT message MUST 200 include Buffer-Control option. The last sequence number received as 201 option value until now The PUT message MUST be confirmable. The 202 Subject receiving the PUT message deletes messages from the buffer 203 which have a smaller sequence number than the sequence number 204 included in the message. In other words, the PUT message acts as a 205 cumulative ACK of TCP. 207 Figure 2 shows a simple example of transferring data. If a message 208 sent by a subject is lost, the observer can send a GET request to 209 request a message of a specific sequence number. The GET request MUST 210 include Buffer-Control and the positive integer number meaning the 211 specific sequence number as. The observer can also stop the streaming 212 service by sending a DELETE message, and the subject deletes the URL 213 when it receives a delete. 215 +---------+ +----------+ 216 | Subject | | Observer | 217 +---------+ +----------+ 218 | 2.05 CONTENT | 219 | Token: 0x72 | 220 | Observe: 0 | 221 | Buffer-Control: 7 | 222 |Payload: Resource Representative| 223 +------------------------------->| 224 | | 225 | 2.05 CONTENT | 226 | Token: 0x72 | 227 | Observe: 1 | 228 | Buffer-Control: 6 | 229 |Payload: Resource Representative| 230 +------------------------------->| 231 | | 232 | 2.05 CONTENT | 233 | Token: 0x72 | 234 | Observe: 2 | 235 | Buffer-Control: 5 | 236 |Payload: Resource Representative| 237 +------------------------------->| 238 | | 239 | PUT /Streaming/stream1 | 240 | Token: 0x73 | 241 | Buffer-Control: 2 | 242 |<-------------------------------+ 243 | 2.05 CONTENT | 244 | Token: 0x72 | 245 | Observe: 3 | 246 | Buffer-Control: 4 | 247 |Payload: Resource Representative| 248 +------------------------------->| 249 | 2.04 CHANGED | 250 | Token: 0x73 | 251 | Buffer-Control: 7 | 252 +------------------------------->| 253 | | 254 | 2.05 CONTENT | 255 | Token: 0x72 | 256 | Observe: 4 | 257 | Buffer-Control: 6 | 258 |Payload: Resource Representative| 259 +------------------------------->| 261 Figure 2: Transferring Data Example 263 2. The Buffer-Control Option 265 The Buffer-Control option has different meanings, depending on the 266 request's method, Option Value, whether it is included in the request 267 for the message, or included in the response. 269 2.1. Buffer-Control Option meaning in request 271 Table 1 shows the meaning of the options depending on the method. 273 +-------+------------------+-------------------------------------+ 274 | | Option Value | Description | 275 +-------+------------------+-------------------------------------+ 276 | GET | Positive Integer |Sequence number of message to request| 277 +-------+------------------+-------------------------------------+ 278 | PUT | 0 | Buffer size to change | 279 +-------+------------------+-------------------------------------+ 280 | PUT | Positive Integer | Sequence number of the last message | 281 +-------+------------------+-------------------------------------+ 282 | POST | 0 | Buffer size to change | 283 +-------+------------------+-------------------------------------+ 285 TABLE 1: Meaning of Buffer-Control Option 287 When included in a GET request, the Buffer-Control Option identifies 288 the specific sequence number of the message. A GET request with the 289 Buffer-Control option is a message that the observer transmits to the 290 subject to request a message that was lost during transmission. In 291 this case, the Buffer-Control option indicates the sequence number of 292 the message to be re-requested, and the option value is a positive 293 integer. 295 When the option is included in a PUT request, the Buffer-Control 296 option has a different meaning depending on the Option value as 297 follows : 299 If the option value is 0, the Buffer-Control option is used to 300 change the buffer size. The buffer size to be changed is 301 included in the payload. 303 If the option value is a positive integer number, the Buffer- 304 Control option is used to empty the subject's buffer. In this 305 case, the option value includes the sequence number of the 306 recently received message, and the Buffer-Control option is 307 used like TCP's cumulative ack. The subject that receives the 308 message containing this option deletes messages whose sequence 309 number is less than or equal to the sequence number contained 310 in the option value of the Buffer-Control option in its buffer. 312 The Buffer-Control option is included in the PUT message and has the 313 same meaning as when the option value is 0. In POST messages, the 314 Buffer-Control option has an option value of only 0. 316 2.2. Buffer-Control Option meaning in a notification 318 When the Buffer-Control option is included in a notification sent 319 from the subject to the observer, that option indicates the size of 320 the buffer that is left over. 322 3. Subject Side Operation 324 3.1. Register 326 The subject who supports streaming service MUST have the resource to 327 make a resource for streaming service. In this specification, the URL 328 of the resource is "/streaming". Also subject MUST be able to handle 329 CoAP Observe Option. 331 3.2. Caching 333 The Subject MUST have a buffer to support Error Control. The buffer 334 size is determined according to the parameters included in the POST 335 message when the POST message for creating the resource for the 336 streaming service is received. 338 3.3. Change the buffer size 340 The Subject MUST have a buffer for error control and be able to 341 change its buffer size. The buffer size is very important in this 342 mechanism. If the size of the buffer is large, the number of PUT 343 messages issued to empty the buffer can be reduced. In addition, the 344 subject maintains the message transmission until the buffer is 345 exhausted without considering other factors, so the observer can 346 perform congestion control by changing the buffer size of 347 the subject. The buffer size is transmitted until the buffer is full 348 and the transmitted message is stored in the buffer. Through the PUT 349 message containing the Buffer-Control option received from the 350 Observer, the messages confirmed to arrive well are deleted from the 351 buffer. 353 3.4. Unregister 355 Since this mechanism basically applies between the sensor and the 356 gateway, the resources created for the streaming service can be 357 observed by only one Observer. Therefore, when a DELETE message is 358 received from the Observer, the corresponding resource should be 359 deleted and the buffer allocated for the streaming service should be 360 released. 362 4. Observer Side Operation 364 4.1. Register 366 An observer who wants streaming service MUST request the creation of 367 a resource for receiving the streaming service. In the extension 368 defined in this specification, a resource for streaming is generated 369 and serviced. Therefore, the observer MUST generate a streaming 370 resource by transmitting a POST message to the subject containing 371 various parameters such as the data resource to be streamed, the 372 buffer size, and the interval between messages. When the resource is 373 successfully created, it receives the resource URL to be streamed 374 from the subject. 376 4.2. Buffer Control 378 For the stability of streaming services, the observer should remove 379 the received message from the subject's buffer. This mechanism 380 minimizes the burden on the subject as much as possible, so the 381 observer MUST be able to manage both the error control and the state 382 of the subject buffer. In addition, it MUST be able to change the 383 subject's buffer size based on network conditions. For example, if 384 the error rate is high, it is possible to control the error by 385 transmitting the PUT message more frequently by reducing the buffer 386 size. If the error rate is low, the buffer size can be increased to 387 reduce the number of control messages issued. 389 4.3. Reordering 391 Since the CoAP message is basically UDP-based, the transmission order 392 and reception order of messages may be different. Therefore, the 393 observer MUST be able to re-order the message using the sequence 394 number included in the CoAP Observe Option. 396 5. Security consideration 398 The security consideration will apply to Section 11 of [RFC7252], 399 the CoAP specification, and Section 7 of [RFC7641], Observing 400 resources in the CoAP. 402 6. IANA Considerations 404 TBD 406 7. References 408 7.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 416 Application Protocol (CoAP)", RFC 7252, DOI 417 10.17487/RFC7252, June 2014, 418 . 420 [RFC7641] Hartke, K., "Observing Resources in the Constrained 421 Application Protocol (CoAP)", RFC 7641, DOI 422 10.17487/RFC7641, September 2015, 423 . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 426 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 427 2017, . 429 Authors' Addresses 431 Joong-Hwa Jung 432 Kyungpook National University 433 Daehakro 80, Bukgu, Daegu, South Korea 41566 435 Email: godopu16@gmail.com 436 Dong-Kyu Choi 437 Kyungpook National University 438 Daehakro 80, Bukgu, Daegu, South Korea 41566 440 Email: supergint@gmail.com 442 Seok-Joo Koh 443 Kyungpook National University 444 Daehakro 80, Bukgu, Daegu, South Korea 41566 446 Phone: +82 53 950 7356 447 Email: sjkoh@knu.ac.kr