idnits 2.17.1 draft-appsawg-perez-sdcp-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 21, 2016) is 2951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ART Area General Applications C. Perez-Monte, Ed. 3 Internet-Draft GridTICs - UTN FRM 4 Intended status: Informational March 21, 2016 5 Expires: September 22, 2016 7 SDCP: Streaming Distributed Control Protocol 8 draft-appsawg-perez-sdcp-00 10 Abstract 12 This memorandum describes SDCP, a protocol to control multimedia 13 streaming in cases where streaming generation should be distributed 14 to improve performance. This is especially useful for Human-Things 15 streams. Usually, real time applications such as virtual reality 16 generate a user-controlled multimedia streaming. This is a time 17 continuous data flux that could be divided spatially to distribute 18 processing, memory or network resources. This protocol does not 19 describe streaming communication, but the control of each single 20 streaming generation in a best-effort by many nodes or things. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Distributed Scheme . . . . . . . . . . . . . . . . . . . . . 4 60 3. SDCP Constant . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Multicast Addressing . . . . . . . . . . . . . . . . . . 5 62 3.2. UDP Ports . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. SDCP Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. General DB Header . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Specific SDS Header . . . . . . . . . . . . . . . . . . . 7 66 4.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Identificators Format . . . . . . . . . . . . . . . . . . . . 8 68 5.1. SDS index . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Node index . . . . . . . . . . . . . . . . . . . . . . . 8 70 6. Payload types . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Streaming considerations . . . . . . . . . . . . . . . . . . 8 72 7.1. Streaming protocols . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Usually, the amount of information transmitted from human to computer 84 is very small. Such is the case of information generated by input 85 devices, for example, keyboards, mouses or touch screens. On the 86 contrary, the amount of information transmitted from computer to 87 human is big. This is increasing over time. Such is the case of 88 information generated by output devices, for example, computer 89 monitors or cellphone screens. Furthermore, the hardware resources 90 such as data processing, network bandwidth or storage are too big. 91 In many applications, human-to-computer control data is required to 92 generate computer-to-human data, such as virtual reality. In this 93 way, human-to-computer control data may be sending to many nodes in 94 multicast method by best-effort delivery and processing. 96 Streaming Distributed Control Protocol (SDCP) is an application-level 97 protocol for control of streaming distributed generation. SDCP is 98 built on the User Datagram Protocol (UDP) [RFC0768], which provides a 99 connection less transport mechanism. SDCP provides the complete 100 information for proper streaming generation. Other mechanism have 101 been specified to transmit multimedia streaming, including the Real 102 Time Streaming Protocol (RTSP) [RFC2326]. The SDCP is not meant to 103 displace this mechanism but rather complement it. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 1.2. Terminology 113 Some clarifications and additional definitions follow: 115 o Multimedia Streaming: It is a group of successive multimedia real- 116 time data blocks in the time. A real-time data block can be an 117 audio level for multimedia audio streaming or a frame for 118 multimedia video streaming. Successive blocks of multimedia 119 streaming must be ordered in time. 121 o Data Block (DB): Data portion of stream with the same shared time 122 slot. 124 o Spatial Data Segment (SDS): Spatial Data segment is subdivision or 125 partition of each Data block to distributed generation. These 126 fragments can be spatial fragment of render image or audio wave 127 channel. 129 o Processor nodes: These nodes generate the multimedia streaming 130 under a distributed scheme. 132 o Administrator Node: This node controls multimedia streaming 133 generation by periodically sending streaming control to the 134 processor nodes. 136 o Integrator node: This node receives multimedia streaming from 137 Processor nodes to display this to a human receptor. 139 Integrator and Administrator nodes are the human-side and Processor 140 nodes are the things-side of the communication system. 142 2. Distributed Scheme 144 Figure 1 shows scheme of a distributed stream generation system. 145 Each processor node has processing, bandwidth or storing resources 146 required for partial stream generation. 148 +------------------------------------------------------------------+ 149 |Remote Administrator Node | 150 +------------------------------------------------------------------+ 151 | Multicast SDCP data communication 152 V 153 +---------------++---------------++---------------++---------------+ 154 |Local Proc Node||Local Proc Node||Local Proc Node||Local Proc Node| 155 +---------------++---------------++---------------++---------------+ 156 ||Uncompressed stream communication 157 \/ 158 +--------------------------------++--------------------------------+ 159 | Local Integrator Node || Local Integrator Node | 160 +--------------------------------++--------------------------------+ 161 ||Compressed stream communication 162 \/ 163 +------------------------------------------------------------------+ 164 | Remote Human Receptors | 165 +------------------------------------------------------------------+ 167 Distributed Scheme. 169 Figure 1 171 Administrator Node sends periodically SDCP multicast control 172 datagrams to Processor Nodes. The use of multicast is mandatory to 173 select processor group id. The amount of SDCP datagrams should be 174 sufficient to compensate losses and to allow real-time operation. 175 These losses may occur by delivery problems or ignored by processor 176 nodes. Administrator Node MAY assign different Processor Node for 177 processing each SDS. 179 Each unoccupied Processor Node receive SDCP datagrams. Occupied 180 Processor Node SHOULD ignore SDCP datagrams. Each Processor Node 181 generates stream portion through the use of more current SDCP control 182 data. This generated stream is sent to appropriate Integrator Node. 184 Integrator Node receives stream portion unicast communication. All 185 the stream portion received are integrated in a single stream that is 186 sent to remote human receptors or locally visualized. 188 Administrator Node MAY assign different destination Integrator Node 189 for each SDS. Each integrator node MAY receive multiple streams, a 190 same DB or multiple/single SDS of multiple Processor Node. However, 191 each SDS is assigned to only one Integrator node. While that 192 different SDS of same stream MAY be assigned to send these to 193 different integrator nodes, each SDS of same stream MUST NOT be sent 194 to more than only one Integrator node. 196 3. SDCP Constant 198 TO DO 200 3.1. Multicast Addressing 202 TO DO 204 3.2. UDP Ports 206 TO DO 208 4. SDCP Format 210 Main SDCP format is shown in figure 2. 212 +-------------------+---------------------+--------+ 213 | General DB Header | Specific SDS Header | Payload| 214 +-------------------+---------------------+--------+ 216 SDCP Format. 218 Figure 2 220 o General DB Header: 224-bits length field. This header is 221 required. Identifies fields from all the DB. 223 o Specific SDS Header: 128-bits length field. This header is 224 optional. Identifies fields from specific SDS. If this header is 225 not present, all SDS of same DB SHOULD be treated equally. 227 o Payload: Variable-length field. Stream Control Data. 229 4.1. General DB Header 231 DB Header is required. 233 0 1 2 3 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |control data type|M| RD | Stream ID | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 | Time stamp (64 bits) | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | SDCP Counter | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Var DB Counter | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | No Var DB Counter | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Payload plus opt header length| Next Header Counter | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 DB Header Format. 253 Figure 3 255 Processor Node or Processor Node Group id is determined by multicast 256 destination address of ip stack. 258 Control data type: 8-bit selector. Type of control streaming 259 generation data. Types are defined in accordance with specific 260 requirement of application. E.g. virtual reality, game or video 261 streaming, drone controller application, etc. 263 Control data mode: 1-bit selector. Instant or Historical Mode. 265 0 - Instant Mode 267 1 - Historical Mode 269 RD: 3-bit selector. Reserved for future use. 271 Stream ID: 20-bit unsigned integer. Multimedia Stream data 272 identificator. 274 Time stamp: 64-bits unsigned fixed-point. It includes a 32-bit 275 unsigned seconds field spanning 136 years and a 32-bit fraction field 276 resolving 232 picoseconds such as RFC 5905 [RFC5905]. This 64-bit 277 timestamp format is used in General DB header and payload. 279 SDCP Counter: 32-bit unsigned integer. Total number of SDCP 280 datagrams sent. 282 Var DB Counter: 32-bit unsigned integer. Total number of SDCP 283 datagrams sent with control data changes. 285 No Var DB Counter: 32-bit unsigned integer. Total number of SDCP 286 datagrams sent from last control data change. 288 Payload plus opt header length: 16-bit unsigned integer. Length of 289 Payload, in 16-octet units. 291 Next Header Counter: 16-bit unsigned integer. Number of Optional SDS 292 Headers. 294 4.2. Specific SDS Header 296 SDS header is optional. This header specifies SDS allocation to 297 nodes. Two functions are defined. On the one hand, this header MAY 298 determine which SDS data are assigned to generate by processor node. 299 On the other hand, this header MAY determine which SDS data are 300 assigned to send from processor node to integrator node. 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 | SDS group ID (64 bits) | 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 | Node group ID (64 bits) | 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 SDS Header Format. 316 Figure 4 318 SDS group ID: 64-bit selector. Identifies individual SDS or SDS 319 group for allocation to nodes. 321 Node group ID: 64-bit selector. Identifies integrator or processor 322 node for its interface identifier from IPv6 unicast destination 323 address or identifies processor node group for its low-order 64 bits 324 of an IPv6 multicast destination address such as IP Version 6 325 Addressing Architecture [RFC2373]. Allocated Processor Node MUST 326 process all SDS assigned in SDS group ID and MUST NOT process SDS not 327 assigned. Non-allocated Processor Node MAY process all SDS. SDS not 328 assigned to any Integrator Node MUST be sent to Default Integrator 329 Node. Similarly, SDS assigned more than one Integrator Node MUST be 330 sent only to Default Integrator Node. 332 4.3. Payload 334 Payload data format is specified in control data type field of 335 general header. This field determine in virtual reality applications 336 variables such as camera positions, light positions, etc. 338 Two modes are supported. 340 Instant Mode: Last change control data is only sent. 342 Historical Mode: All changes control data are sent. 344 Types of control data: TO DO. 346 5. Identificators Format 348 TO DO 350 5.1. SDS index 352 TO DO 354 5.2. Node index 356 TO DO 358 6. Payload types 360 TO DO 362 7. Streaming considerations 364 TO DO 366 7.1. Streaming protocols 368 TO DO 370 8. Acknowledgements 372 I would like to thank the resources and support of GRIDTICS and 373 LICPaD of the Universidad Tecnologica Nacional Regional Mendoza (UTN 374 FRM), LIDIC of the Universidad Nacional de San Luis (UNSL), the Joint 375 Laboratory for System Evaluation (JLSE) at Argonne National 376 Laboratory and Dept. of Bioengineering, Dept. of Biomedical and 377 Health Information Sciences to the University of Illinois at Chicago 378 (UIC). Especially, I am deeply grateful to Gustavo Mercado, 379 Christian O'Flaherty, Ines Robles and Gabriel Montenegro for their 380 support. 382 9. IANA Considerations 384 This memo includes no request to IANA. 386 10. Security Considerations 388 TO DO 390 11. References 392 11.1. Normative References 394 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 395 DOI 10.17487/RFC0768, August 1980, 396 . 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 11.2. Informative References 405 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 406 Streaming Protocol (RTSP)", RFC 2326, 407 DOI 10.17487/RFC2326, April 1998, 408 . 410 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 411 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 412 . 414 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 415 "Network Time Protocol Version 4: Protocol and Algorithms 416 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 417 . 419 Author's Address 421 Cristian Federico Perez-Monte (editor) 422 GridTICs - UTN FRM 423 Rodriguez 273 Cuarto Piso Bloque Dpto Electronica 424 Ciudad de Mendoza, Mendoza M5502AJE 425 AR 427 Phone: +54 261 524 4563 428 Email: cristian.perez@gridtics.frm.utn.edu.ar