idnits 2.17.1 draft-perez-dispatch-sdcp-04.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 (July 19, 2018) is 2108 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: January 20, 2019 July 19, 2018 7 SDCP: Streaming Distributed Control Protocol 8 draft-perez-dispatch-sdcp-04 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 https://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 January 20, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Specific SDS Header . . . . . . . . . . . . . . . . . . . 7 66 4.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Identificators Format . . . . . . . . . . . . . . . . . . . . 9 68 5.1. SDS index . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. Node index . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Payload types . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 sent to many 94 nodes in multicast method by best-effort delivery and processing. 95 The protocol has been implemented by [Perez-Monte14] [Perez-Monte16b] 96 with good results and its has been descripted in detail by 97 [Perez-Monte16]. 99 Streaming Distributed Control Protocol (SDCP) is an application-level 100 protocol for control of streaming distributed generation. SDCP is 101 built over the User Datagram Protocol (UDP) [RFC0768] or the 102 Lightweight User Datagram Protocol (UDP-Lite) [RFC3828], which 103 provides a connection less deterministic transport mechanism. SDCP 104 provides the complete information for suitable streaming distributed 105 generation. Other mechanism have been specified to transmit 106 multimedia streaming, including the Real Time Streaming Protocol 107 (RTSP) [RFC2326]. The SDCP is not meant to displace this mechanism 108 but rather complement it. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 1.2. Terminology 118 Some clarifications and additional definitions follow: 120 o Multimedia Streaming: It is a group of successive multimedia real- 121 time data blocks over time. A real-time data block can be an 122 audio level for multimedia audio streaming or a frame for 123 multimedia video streaming. Successive blocks of multimedia 124 streaming must be ordered in time. 126 o Data Block (DB): Data portion of stream with the same shared time 127 slot. 129 o Spatial Data Segment (SDS): Spatial Data segment is subdivision or 130 partition of each Data block to distributed generation. These 131 fragments could be a piece of a render image. 133 o Processor nodes: These nodes generate the multimedia streaming 134 under a distributed scheme. 136 o Administrator Node: This node controls multimedia streaming 137 generation by periodically sending streaming control to the 138 processor nodes. 140 o Integrator node: This node receives multimedia streaming from 141 Processor nodes to display this to a human receptor. 143 Integrator and Administrator nodes are the human-side and Processor 144 nodes are the things-side of the communication system. 146 2. Distributed Scheme 148 Figure 1 shows scheme of a distributed stream generation system. 149 Each processor node has processing, bandwidth or storing resources 150 for partial stream generation. 152 +------------------------------------------------------------------+ 153 |Remote Administrator Node | 154 +------------------------------------------------------------------+ 155 | Multicast SDCP data communication 156 V 157 +---------------++---------------++---------------++---------------+ 158 |Local Proc Node||Local Proc Node||Local Proc Node||Local Proc Node| 159 +---------------++---------------++---------------++---------------+ 160 ||Uncompressed stream communication 161 \/ 162 +--------------------------------++--------------------------------+ 163 | Local Integrator Node || Local Integrator Node | 164 +--------------------------------++--------------------------------+ 165 ||Compressed stream communication 166 \/ 167 +------------------------------------------------------------------+ 168 | Remote Human Receptors | 169 +------------------------------------------------------------------+ 171 Distributed Scheme. 173 Figure 1 175 Administrator Node sends periodically SDCP multicast control 176 datagrams to Processor Nodes. The use of multicast is mandatory to 177 select processor group ID. The amount of SDCP datagrams should be 178 sufficient to compensate losses and to allow real-time operation. 179 These losses may occur by delivery problems or it could be ignored 180 datagrams by processor nodes. Administrator Node MAY assign 181 different Processor Node for processing each SDS. 183 Each unoccupied Processor Node receives SDCP datagrams. Occupied 184 Processor Node SHOULD ignore SDCP datagrams. Each Processor Node 185 generates stream portion through the use of more current SDCP control 186 data. This generated stream is sent to an appropriate Integrator 187 Node. 189 Integrator Node receives stream portion unicast communication. All 190 the stream portion received are integrated in a single stream that is 191 sent to remote human receptors or locally visualized. 193 Administrator Node MAY assign different destination Integrator Node 194 for each SDS. Each Integrator node MAY receive multiple streams, a 195 same DB or multiple/single SDS of multiple Processor Node. However, 196 each SDS is assigned to only one Integrator node. While that 197 different SDS of the same stream MAY be assigned to send these to 198 different integrator nodes, each SDS of the same stream MUST NOT be 199 sent to more than only one Integrator node. 201 3. SDCP Constant 203 TO DO 205 3.1. Multicast Addressing 207 TO DO 209 3.2. UDP Ports 211 TO DO 213 4. SDCP Format 215 Main SDCP format is shown in figure 2. 217 +-------------------+---------------------+--------+ 218 | General DB Header | Specific SDS Header | Payload| 219 +-------------------+---------------------+--------+ 221 SDCP Format. 223 Figure 2 225 o General DB Header: 256-bits length field. This header is required 226 and identifies fields from all the DB. 228 o Specific SDS Header: Multiple of 128-bits, variable-length field. 229 This header is optional and identifies fields from specific SDS. 230 If this header is not present, all SDS of same DB SHOULD be 231 treated equally. 233 o Payload: Variable-length field. Stream Control Data. 235 4.1. General DB Header 237 DB Header is required. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |control data type|M| RD | Stream Generation Source ID | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 | Timestamp (64 bits) | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | SDCP Counter | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Var DB Counter | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | DB size | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | SDS size | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | DB Type | Next Header Counter | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 DB Header Format. 261 Figure 3 263 Processor Node or Processor Node Group 64 bit ID is determined by 264 multicast destination address of IP stack. 266 Control data type: 8-bit selector. Type of control streaming 267 generation data. Types are defined in accordance with specific 268 requirement of application. E.g. virtual reality, game or video 269 streaming, drone controller application, etc. 271 Control data mode: 1-bit selector. Instant or Historical Mode. 273 0 - Instant Mode: The payload has the last control data configuration 274 for the Processor Nodes, which means that the Administrator Node 275 sends control data in a deterministic way with the last setup. 277 1 - Historical Mode: Administrator Node sends previous and actual 278 control data to the processor nodes, in order to help them to 279 generate the next streaming sequence. 281 RD: 3-bit selector. Reserved for future use. 283 Streaming Generation Source ID: 20-bit unsigned integer. Multimedia 284 generation data source identification. It identifies the data source 285 generating multimedia stream. 287 Timestamp: 64-bits unsigned fixed-point. It includes a 32-bit 288 unsigned seconds field spanning 136 years and a 32-bit fraction field 289 resolving 232 picoseconds such as RFC 5905 [RFC5905]. This 64-bit 290 timestamp format is used in General DB header and payload. 292 SDCP Counter: 32-bit unsigned integer. Total number of SDCP 293 datagrams sent. 295 Var DB Counter: 32-bit unsigned integer. Total number of SDCP 296 datagrams sent with control data changes. 298 DB type: 16-bit unsigned integer. 300 DB size: 32-bit unsigned integer. 302 SDS size: 32-bit unsigned integer. 304 Next Header Counter: 16-bit unsigned integer. Number of Optional SDS 305 Headers. Length of optional headers in 16-octet units. 307 4.2. Specific SDS Header 309 SDS header is optional. This header specifies SDS allocation to 310 nodes. Two functions are defined. On the one hand, this header MAY 311 determine which SDS data are assigned to generate by processor node. 312 On the other hand, this header MAY determine which SDS data are 313 assigned to send from processor node to integrator node. Each unique 314 64 bit id can identify a node, node group and node role or SDS data 315 task or SDS data task group. The node roles are processor, 316 integrator and administrator but others roles can be defined. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | SDS task ID (64 bits) | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | Resource ID (64 bits) | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 SDS Header Format. 332 Figure 4 334 SDS task ID: 64-bit selector. It identifies individual SDS task or 335 SDS group tasks for allocation to nodes. The tasks already assigned 336 to a node can also assigned to other node by setting SDS task ID with 337 its node ID. 339 Resource ID: 64-bit selector, identifies integrator or processor node 340 from its interface identifier from IPv6 unicast destination address 341 or identifies processor node group from its low-order 64 bits of an 342 IPv6 multicast destination address such as IP Version 6 Addressing 343 Architecture [RFC2373]. Allocated Processor Node MUST process all 344 SDS assigned in SDS group ID and MUST NOT process SDS not assigned. 345 Non-allocated Processor Node MAY process all SDS. SDS not assigned 346 to any Integrator Node MUST be sent to Default Integrator Node. 347 Similarly, SDS assigned more than one Integrator Node MUST be sent 348 only to Default Integrator Node. 350 4.3. Payload 352 Payload data format is specified in control data type field of 353 general header. This field determines in virtual reality 354 applications variables such as camera positions, light positions, 355 etc. 357 Two modes are supported. 359 Instant Mode: Last change control data is only sent. 361 Historical Mode: All changes control data are sent. 363 Types of control data: TO DO. 365 5. Identificators Format 367 TO DO 369 5.1. SDS index 371 TO DO 373 5.2. Node index 375 TO DO 377 6. Payload types 379 TO DO 381 7. Streaming considerations 383 TO DO 385 7.1. Streaming protocols 387 TO DO 389 8. Acknowledgements 391 I would like to thank the resources and support of GRIDTICS and 392 LICPaD of the Universidad Tecnologica Nacional Regional Mendoza (UTN 393 FRM), LIDIC of the Universidad Nacional de San Luis (UNSL), the Joint 394 Laboratory for System Evaluation (JLSE) at Argonne National 395 Laboratory and Dept. of Bioengineering, Dept. of Biomedical and 396 Health Information Sciences to the University of Illinois at Chicago 397 (UIC). Especially, I am deeply grateful to Gustavo Mercado, 398 Christian O'Flaherty, Ines Robles and Gabriel Montenegro for their 399 support. 401 9. IANA Considerations 403 This memo includes no request to IANA. 405 10. Security Considerations 407 TO DO 409 11. References 411 11.1. Normative References 413 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 414 DOI 10.17487/RFC0768, August 1980, 415 . 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 423 and G. Fairhurst, Ed., "The Lightweight User Datagram 424 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 425 2004, . 427 11.2. Informative References 429 [Perez-Monte14] 430 Perez-Monte, C., Mercado, G., Taffernaberry, J., and M. 431 Piccoli, "Protocolo de comunicaciones para renderizacion 432 distribuida en tiempo real - I Workshop Pre-IETF", 2014. 434 [Perez-Monte16] 435 Perez-Monte, C., Perez, M., Luciano, C., Rizzi, S., and M. 436 Piccoli, "Protocolo de comunicaciones para control de la 437 generacion distribuida de flujo multimedia - WPIETFIRTF - 438 III Workshop Pre-IETF/IRTF", 2016. 440 [Perez-Monte16b] 441 Perez-Monte, C., Perez, M., Luciano, C., Rizzi, S., and M. 442 Piccoli, "Modelling frame losses in a parallel Alternate 443 Frame Rendering system with a Computational Best-effort 444 Scheme", 2016. 446 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 447 Streaming Protocol (RTSP)", RFC 2326, 448 DOI 10.17487/RFC2326, April 1998, 449 . 451 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 452 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 453 . 455 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 456 "Network Time Protocol Version 4: Protocol and Algorithms 457 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 458 . 460 Authors' Addresses 462 Cristian Federico Perez-Monte (editor) 463 GridTICs - UTN FRM 464 Rodriguez 273 Cuarto Piso Bloque Dpto Electronica 465 Ciudad de Mendoza, Mendoza M5502AJE 466 AR 468 Phone: +54 261 524 4563 469 Email: cristian.perez@gridtics.frm.utn.edu.ar 471 Ana Laura Diedrichs 472 GridTICs - UTN FRM 473 Rodriguez 273 Cuarto Piso Bloque Dpto Electronica 474 Ciudad de Mendoza, Mendoza M5502AJE 475 AR 477 Phone: +54 261 524 4563 478 Email: ana.diedrichs@gridtics.frm.utn.edu.ar