idnits 2.17.1 draft-perez-dispatch-sdcp-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 (January 2, 2017) is 2671 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 Dispatch C. Perez-Monte, Ed. 3 Internet-Draft A. Diedrichs 4 Intended status: Informational GridTICs - UTN FRM 5 Expires: July 6, 2017 January 2, 2017 7 SDCP: Streaming Distributed Control Protocol 8 draft-perez-dispatch-sdcp-01 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 or temporally to 18 distribute processing, memory or network resources. This protocol 19 does not describe streaming communication, but the control of each 20 single 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 July 6, 2017. 39 Copyright Notice 41 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 9 72 7.1. Streaming protocols . . . . . . . . . . . . . . . . . . . 9 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 The amount of information transmitted from human-to-computer (H2C) is 84 usually very small. This is the case of information generated by 85 input devices, for example, keyboards, mouses or touch screens. 86 Conversely, the amount of information transmitted from computer-to- 87 human (C2H) is huge which is increasing over time. This is the case 88 of information generated for output devices, such as computer 89 monitors, mobile phone screens or virtual reality headsets. 90 Furthermore, the hardware resources such as data processing, network 91 bandwidth or storage are also considerable. H2C control data is 92 required to generate C2H data, such as virtual reality and other 93 applications. In this way, H2C control data may be sending to many 94 nodes in multicast method by best-effort delivery and processing. 95 The protocol has been implemented by [Perez-Monte14] with good 96 results and its has been descripted in detail by [Perez-Monte16]. 98 Streaming Distributed Control Protocol (SDCP) is an application-level 99 protocol for control of streaming distributed generation. SDCP is 100 built over the User Datagram Protocol (UDP) [RFC0768] or the 101 Lightweight User Datagram Protocol (UDP-Lite) [RFC3828], which 102 provides a connection less deterministic transport mechanism. SDCP 103 provides the complete information for suitable streaming distributed 104 generation. Other mechanism have been specified to transmit 105 multimedia streaming, including the Real Time Streaming Protocol 106 (RTSP) [RFC2326]. The SDCP is not meant to displace this mechanism 107 but rather complement it. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 1.2. Terminology 117 Some clarifications and additional definitions follow: 119 o Multimedia Streaming: It is a group of successive multimedia real- 120 time data blocks over time. A real-time data block can be an 121 audio level for multimedia audio streaming or a frame for 122 multimedia video streaming. Successive blocks of multimedia 123 streaming must be ordered in time. 125 o Data Block (DB): Data portion of stream with the same shared time 126 slot. 128 o Spatial Data Segment (SDS): Spatial Data segment is subdivision or 129 partition of each Data block to distributed generation. These 130 fragments could be a piece of a render image. 132 o Processor nodes: These nodes generate the multimedia streaming 133 under a distributed scheme. 135 o Administrator Node: This node controls multimedia streaming 136 generation by periodically sending streaming control to the 137 processor nodes. 139 o Integrator node: This node receives multimedia streaming from 140 Processor nodes to display this to a human receptor. 142 Integrator and Administrator nodes are the human-side and Processor 143 nodes are the things-side of the communication system. 145 2. Distributed Scheme 147 Figure 1 shows scheme of a distributed stream generation system. 148 Each processor node has processing, bandwidth or storing resources 149 for partial stream generation. 151 +------------------------------------------------------------------+ 152 |Remote Administrator Node | 153 +------------------------------------------------------------------+ 154 | Multicast SDCP data communication 155 V 156 +---------------++---------------++---------------++---------------+ 157 |Local Proc Node||Local Proc Node||Local Proc Node||Local Proc Node| 158 +---------------++---------------++---------------++---------------+ 159 ||Uncompressed stream communication 160 \/ 161 +--------------------------------++--------------------------------+ 162 | Local Integrator Node || Local Integrator Node | 163 +--------------------------------++--------------------------------+ 164 ||Compressed stream communication 165 \/ 166 +------------------------------------------------------------------+ 167 | Remote Human Receptors | 168 +------------------------------------------------------------------+ 170 Distributed Scheme. 172 Figure 1 174 Administrator Node sends periodically SDCP multicast control 175 datagrams to Processor Nodes. The use of multicast is mandatory to 176 select processor group ID. The amount of SDCP datagrams should be 177 sufficient to compensate losses and to allow real-time operation. 178 These losses may occur by delivery problems or it could be ignored 179 datagrams by processor nodes. Administrator Node MAY assign 180 different Processor Node for processing each SDS. 182 Each unoccupied Processor Node receive SDCP datagrams. Occupied 183 Processor Node SHOULD ignore SDCP datagrams. Each Processor Node 184 generates stream portion through the use of more current SDCP control 185 data. This generated stream is sent to an appropriate Integrator 186 Node. 188 Integrator Node receives stream portion unicast communication. All 189 the stream portion received are integrated in a single stream that is 190 sent to remote human receptors or locally visualized. 192 Administrator Node MAY assign different destination Integrator Node 193 for each SDS. Each integrator node MAY receive multiple streams, a 194 same DB or multiple/single SDS of multiple Processor Node. However, 195 each SDS is assigned to only one Integrator node. While that 196 different SDS of same stream MAY be assigned to send these to 197 different integrator nodes, each SDS of same stream MUST NOT be sent 198 to more than only one Integrator node. 200 3. SDCP Constant 202 TO DO 204 3.1. Multicast Addressing 206 TO DO 208 3.2. UDP Ports 210 TO DO 212 4. SDCP Format 214 Main SDCP format is shown in figure 2. 216 +-------------------+---------------------+--------+ 217 | General DB Header | Specific SDS Header | Payload| 218 +-------------------+---------------------+--------+ 220 SDCP Format. 222 Figure 2 224 o General DB Header: 256-bits length field. This header is required 225 and identifies fields from all the DB. 227 o Specific SDS Header: Multiple of 128-bits, variable-length field. 228 This header is optional and identifies fields from specific SDS. 229 If this header is not present, all SDS of same DB SHOULD be 230 treated equally. 232 o Payload: Variable-length field. Stream Control Data. 234 4.1. General DB Header 236 DB Header is required. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |control data type|M| RD | Stream Generation Source ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 | Timestamp (64 bits) | 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | SDCP Counter | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Var DB Counter | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | DB size | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | SDS size | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | DB Type | Next Header Counter | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 DB Header Format. 260 Figure 3 262 Processor Node or Processor Node Group 64 bit ID is determined by 263 multicast destination address of IP stack. 265 Control data type: 8-bit selector. Type of control streaming 266 generation data. Types are defined in accordance with specific 267 requirement of application. E.g. virtual reality, game or video 268 streaming, drone controller application, etc. 270 Control data mode: 1-bit selector. Instant or Historical Mode. 272 0 - Instant Mode: The payload has the last control data configuration 273 for the Processor Nodes, which means that the Administrator Node 274 sends control data in a deterministic way with the last setup. 276 1 - Historical Mode: Administrator Node sends previous and actual 277 control data to the processor nodes, in order to help them to 278 generate the next streaming sequence. 280 RD: 3-bit selector. Reserved for future use. 282 Streaming Generation Source ID: 20-bit unsigned integer. Multimedia 283 generation data source identification. It identifies the data source 284 generating multimedia stream. 286 Timestamp: 64-bits unsigned fixed-point. It includes a 32-bit 287 unsigned seconds field spanning 136 years and a 32-bit fraction field 288 resolving 232 picoseconds such as RFC 5905 [RFC5905]. This 64-bit 289 timestamp format is used in General DB header and payload. 291 SDCP Counter: 32-bit unsigned integer. Total number of SDCP 292 datagrams sent. 294 Var DB Counter: 32-bit unsigned integer. Total number of SDCP 295 datagrams sent with control data changes. 297 DB type: 16-bit unsigned integer. 299 DB size: 32-bit unsigned integer. 301 SDS size: 32-bit unsigned integer. 303 Next Header Counter: 16-bit unsigned integer. Number of Optional SDS 304 Headers. Length of optional headers in 16-octet units. 306 4.2. Specific SDS Header 308 SDS header is optional. This header specifies SDS allocation to 309 nodes. Two functions are defined. On the one hand, this header MAY 310 determine which SDS data are assigned to generate by processor node. 311 On the other hand, this header MAY determine which SDS data are 312 assigned to send from processor node to integrator node. Each unique 313 64 bit id can identify a node, node group and node role or SDS data 314 task or SDS data task group. The node roles are processor, 315 integrator and administrator but others roles can be defined. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 | SDS task ID (64 bits) | 322 | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | | 325 | Resource ID (64 bits) | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 SDS Header Format. 331 Figure 4 333 SDS task ID: 64-bit selector. It identifies individual SDS task or 334 SDS group tasks for allocation to nodes. The tasks already assigned 335 to a node can also assigned to other node by setting SDS task ID with 336 its node ID. 338 Resource ID: 64-bit selector, identifies integrator or processor node 339 from its interface identifier from IPv6 unicast destination address 340 or identifies processor node group from its low-order 64 bits of an 341 IPv6 multicast destination address such as IP Version 6 Addressing 342 Architecture [RFC2373]. Allocated Processor Node MUST process all 343 SDS assigned in SDS group ID and MUST NOT process SDS not assigned. 344 Non-allocated Processor Node MAY process all SDS. SDS not assigned 345 to any Integrator Node MUST be sent to Default Integrator Node. 346 Similarly, SDS assigned more than one Integrator Node MUST be sent 347 only to Default Integrator Node. 349 4.3. Payload 351 Payload data format is specified in control data type field of 352 general header. This field determines in virtual reality 353 applications variables such as camera positions, light positions, 354 etc. 356 Two modes are supported. 358 Instant Mode: Last change control data is only sent. 360 Historical Mode: All changes control data are sent. 362 Types of control data: TO DO. 364 5. Identificators Format 366 TO DO 368 5.1. SDS index 370 TO DO 372 5.2. Node index 374 TO DO 376 6. Payload types 378 TO DO 380 7. Streaming considerations 382 TO DO 384 7.1. Streaming protocols 386 TO DO 388 8. Acknowledgements 390 I would like to thank the resources and support of GRIDTICS and 391 LICPaD of the Universidad Tecnologica Nacional Regional Mendoza (UTN 392 FRM), LIDIC of the Universidad Nacional de San Luis (UNSL), the Joint 393 Laboratory for System Evaluation (JLSE) at Argonne National 394 Laboratory and Dept. of Bioengineering, Dept. of Biomedical and 395 Health Information Sciences to the University of Illinois at Chicago 396 (UIC). Especially, I am deeply grateful to Gustavo Mercado, 397 Christian O'Flaherty, Ines Robles and Gabriel Montenegro for their 398 support. 400 9. IANA Considerations 402 This memo includes no request to IANA. 404 10. Security Considerations 406 TO DO 408 11. References 410 11.1. Normative References 412 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 413 DOI 10.17487/RFC0768, August 1980, 414 . 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, 418 DOI 10.17487/RFC2119, March 1997, 419 . 421 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 422 and G. Fairhurst, Ed., "The Lightweight User Datagram 423 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 424 2004, . 426 11.2. Informative References 428 [Perez-Monte14] 429 Perez-Monte, C., Mercado, G., Taffernaberry, J., and M. 430 Piccoli, "Protocolo de comunicaciones para renderizacion 431 distribuida en tiempo real - I Workshop Pre-IETF", 2014. 433 [Perez-Monte16] 434 Perez-Monte, C., Perez, M., Luciano, C., Rizzi, S., and M. 435 Piccoli, "Protocolo de comunicaciones para control de la 436 generacion distribuida de flujo multimedia - WPIETFIRTF - 437 III Workshop Pre-IETF/IRTF", 2016. 439 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 440 Streaming Protocol (RTSP)", RFC 2326, 441 DOI 10.17487/RFC2326, April 1998, 442 . 444 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 446 . 448 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 449 "Network Time Protocol Version 4: Protocol and Algorithms 450 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 451 . 453 Authors' Addresses 455 Cristian Federico Perez-Monte (editor) 456 GridTICs - UTN FRM 457 Rodriguez 273 Cuarto Piso Bloque Dpto Electronica 458 Ciudad de Mendoza, Mendoza M5502AJE 459 AR 461 Phone: +54 261 524 4563 462 Email: cristian.perez@gridtics.frm.utn.edu.ar 464 Ana Laura Diedrichs 465 GridTICs - UTN FRM 466 Rodriguez 273 Cuarto Piso Bloque Dpto Electronica 467 Ciudad de Mendoza, Mendoza M5502AJE 468 AR 470 Phone: +54 261 524 4563 471 Email: ana.diedrichs@gridtics.frm.utn.edu.ar