idnits 2.17.1 draft-loreto-core-coap-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 (March 27, 2012) is 4413 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) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-05 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 core S. Loreto 3 Internet-Draft O. Novo 4 Intended status: Standards Track Ericsson 5 Expires: September 28, 2012 March 27, 2012 7 CoAP Streaming 8 draft-loreto-core-coap-streaming-00 10 Abstract 12 This specification defines a simple mechanism for streaming media 13 data from a server to a client in a constrained network over CoAP. 14 The mechanism take advantage of the observer design pattern described 15 in CoAP, extending it, to support streaming media transfer between 16 nodes. 18 Note 20 Discussion and suggestions for improvement are requested, and should 21 be sent to core@ietf.org. 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 http://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 September 28, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. COAP Streaming Extension . . . . . . . . . . . . . . . . . . . 3 60 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. CoAP Streaming negotiation . . . . . . . . . . . . . . . . 6 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The Constrained Application Protocol (CoAP)[I-D.ietf-core-coap] is a 73 specialized web transfer protocol used with constrained networks and 74 nodes for machine-to-machine applications. 76 CoAP has a number of extensions. One of its extensions is the 77 "Observing Resource in CoAP" draft [I-D.ietf-core-observe]. The 78 "Observing Resource in CoAP" draft defines a mechanism to push 79 resource representations from servers to interested clients. 81 However, the CoAP specification or any of its extensions do not 82 define any mechanism to transfer media information between the nodes. 83 If a node in a constrained network wants to transfer some streaming 84 media information with any other node, it does not have any specific 85 mechanism to do so. 87 The main purpose of this document is to extend the "Observing 88 Resource in CoAP" draft [I-D.ietf-core-observe] to support streaming 89 media transfer between the nodes. 91 In addition, this specification adds a new option Streaming to the 92 Constrained Application Protocol (CoAP). The main purpose of this 93 option is to indicate when a message will break into chunks of known 94 size. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. COAP Streaming Extension 104 2.1. Definition 106 The CoAP Streaming mechanism extends the "Observing Resource in CoAP" 107 draft [I-D.ietf-core-observe]. The basic life cycle of an 108 application using CoAP streaming is as follows: 110 o The client registers itself with a resource by performing a GET 111 request that includes an Observe Option. The registration process 112 is defined in the "Observing Resource in CoAP" draft 113 [I-D.ietf-core-observe]. 115 o If the observation relationship is established between the server 116 and the client, the server sends a CoAP streaming response to the 117 client, including the Observe Option, whenever some new media 118 chuck is available. 120 A CoAP streaming response includes the following options: 122 o The Observe and Token defined in the "Observing Resource in CoAP" 123 draft [I-D.ietf-core-observe]. 125 o A New Option header called 'streaming' that indicates the message 126 will break into chunks of known size. 128 o End of File (EOF) that indicates the end of the transmission of 129 the media. This value will help to differentiate between a 130 connection terminated by a fault and one that is correctly 131 terminated. 133 The following example includes a media chunk in the observation 134 message: 136 2.05 Content 137 Observe: 12 138 Token: 0x4a 139 Streaming: chunked 140 Payload: 141 This is the data in the first chunk 143 Figure 1: Transfer response 145 The CoAP streaming mechanism is based on the capability of the server 146 to send several pieces of information in different responses. 148 Figure 2 illustrates the media communication between client and 149 server. 151 Client Server 152 | | 153 | | 154 | | 155 |GET /videocamera | 156 | Observe: 0 | 157 | Token: 0x4a | 158 |----------------------->| 159 | | 160 | | 161 |2.05 Content | 162 | Observe: 1 | 163 | Token: 0x4a | 164 | Streaming: chunked | 165 | Content-Type: 0 | 166 | Payload: | 167 | First chuck | 168 |<-----------------------| 169 | | 170 | | 171 |2.05 Content | 172 | Observe: 2 | 173 | Token: 0x4a | 174 | Streaming: chunked | 175 | Content-Type: 0 | 176 | Payload: | 177 | Second chuck | 178 |<-----------------------| 179 | | 180 | | 181 | | 182 | | 184 Figure 2: Observing a Media Resource in COAP 186 A notification containing a chunk can be confirmable or non- 187 confirmable (i.e. sent in a confirmable or non-confirmable message). 188 However, all the notifications using the mechanism defined in this 189 draft MUST use non-confirmable messages. 191 The server MUST set the value of the Observe Option in each 192 notification to the 16 least-significant bits of a strictly 193 increasing sequence number that MUST contain no gap. If there is no 194 gap in the Observe Option between two sequence notification a client 195 is receiving, no chunk has been lost or delayed by the network. 197 Note that, differently from what specified in Section 4.4 of 198 [I-D.ietf-core-observe], a server can send more than one notification 199 per second per client, token and resource. The server can then 200 happen to reuse the same option value with the same client, token and 201 resource within approximately 2**16 seconds (roughly 18.2 hours). 203 Since CoAP runs over UDP, chunks (i.e. notifications) can arrive to 204 the client in a different order than they were sent or a chunk can be 205 lost. The ordering of the chunks is determined by the Observe option 206 that, in this case, can be seen as similar to the "sequence number" 207 of the RTP [RFC3550]. It is left to the application to choose the 208 appropriate action, if any, when it detects that a chunk is missing. 210 A notification containing a chunk is made up of the bytes after the 211 options, if any; its maximum length SHOULD be 1280 bytes. 213 The chunks are encoded as "text/plain; charset=utf-8" setting the 214 Content-Type option to 0. How the media is translated to text format 215 is out of the scope of this document. 217 2.2. CoAP Streaming negotiation 219 Figure 3 illustrates a client discovering the different codecs a 220 resource (i.e. videocamera) on a server supports, using the Core 221 Resource Discovery mechanism [I-D.ietf-core-link-format]. 223 The client then chooses a proper code to observe selecting the right 224 URI. 226 Client Server 227 | | 228 | | 229 | | 230 | GET /.well-known/core?rt=videocamera| 231 |------------------------------------>| 232 | | 233 | | 234 |2.05 Content | 235 | ;rt="videocamera" | 236 | ;rt="videocamera" | 237 |<------------------------------------| 238 | | 239 | | 240 |GET /videocamera/MPEG | 241 | Observe: 0 | 242 | Token: 0x4a | 243 |------------------------------------>| 244 | | 245 | | 246 |2.05 Content | 247 | Observe: 1 | 248 | Token: 0x4a | 249 | Streaming: chunked | 250 | Content-Type: 0 | 251 | Payload: | 252 | First chuck | 253 |<------------------------------------| 254 | | 255 | | 256 |2.05 Content | 257 | Observe: 2 | 258 | Token: 0x4a | 259 | Streaming: chunked | 260 | Content-Type: 0 | 261 | Payload: | 262 | Second chuck | 263 |<------------------------------------| 264 | | 266 Figure 3: Media negotiation 268 3. Security Considerations 270 This presents no security considerations beyond those in section 8 of 271 the Observing Resources in CoAP specification [I-D.ietf-core-observe] 272 . 274 4. IANA Considerations 276 The IANA is requested to add the following "CoAP Option Numbers" 277 entry as per Section 11.2 of [I-D.ietf-core-coap]. 279 +--------+------------------+----------------+ 280 | Number | Name | Reference | 281 +--------+------------------+----------------+ 282 | 23 | Streaming | Section 2 | 283 +--------+------------------+----------------+ 285 5. Acknowledgements 287 The authors of this draft would like to thank Heidi-Maria Rissanen. 289 6. References 291 6.1. Normative References 293 [I-D.ietf-core-coap] 294 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 295 "Constrained Application Protocol (CoAP)", 296 draft-ietf-core-coap-09 (work in progress), March 2012. 298 [I-D.ietf-core-observe] 299 Hartke, K., "Observing Resources in CoAP", 300 draft-ietf-core-observe-05 (work in progress), March 2012. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, March 1997. 305 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 306 Jacobson, "RTP: A Transport Protocol for Real-Time 307 Applications", STD 64, RFC 3550, July 2003. 309 6.2. Informative References 311 [I-D.ietf-core-link-format] 312 Shelby, Z., "CoRE Link Format", 313 draft-ietf-core-link-format-11 (work in progress), 314 January 2012. 316 Authors' Addresses 318 Salvatore Loreto 319 Ericsson 320 Hirsalantie 11 321 Jorvas 02420 322 Finland 324 Email: salvatore.loreto@ericsson.com 326 Oscar Novo 327 Ericsson 328 Hirsalantie 11 329 Jorvas 02420 330 Finland 332 Email: oscar.novo@ericsson.com