idnits 2.17.1 draft-jesup-rtcweb-data-protocol-03.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 (September 7, 2012) is 4249 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-01 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-04 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWeb Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Loreto 5 Expires: March 11, 2013 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 September 7, 2012 10 WebRTC Data Channel Protocol 11 draft-jesup-rtcweb-data-protocol-03.txt 13 Abstract 15 The Web Real-Time Communication (WebRTC) working group is charged to 16 provide protocols to support for direct interactive rich 17 communication using audio, video, and data between two peers' web- 18 browsers. This document specifies an actual (minor) protocol for how 19 the JS-layer dataChannel objects provide the data channels between 20 the peers. 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 March 11, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. DATA_CHANNEL_OPEN_REQUEST Message . . . . . . . . . . . . 4 62 5.2. DATA_CHANNEL_OPEN_RESPONSE Message . . . . . . . . . . . . 5 63 5.3. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . . 6 64 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Adding a Channel . . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Closing a Channel . . . . . . . . . . . . . . . . . . . . 7 67 6.3. Sending and Receiving Data . . . . . . . . . . . . . . . . 7 68 6.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 7 69 7. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Startup considerations . . . . . . . . . . . . . . . . . . 8 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 11.2. Informational References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 The Data Channel Protocol is designed to provide, in the WebRTC 82 context [I-D.ietf-rtcweb-overview], a generic transport service 83 allowing Web Browser to exchange generic data in a bidirectional peer 84 to peer fashion. As discussed in [I-D.ietf-rtcweb-data-channel] the 85 protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960] 86 encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] as 87 described in [I-D.tuexen-tsvwg-sctp-dtls-encaps] to benefit from 88 their already standardized transport and security features. 90 2. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Terminology 98 This document uses the following terms: 99 Association: An SCTP association. 100 Stream: A unidirectional stream of an SCTP association. It is 101 uniquely identified by a stream identifier. 102 Channel: A bidirectional channel consisting of two SCTP streams. 104 4. Opening Handshake 106 The opening handshake is based on the multimedia session description 107 exchange that happens between the browsers, typically through a Web 108 Server acting as the signaling service. 110 [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'SCTP/ 111 DTLS', and defines how to establish an SCTP association over DTLS 112 using the Session Description Protocol (SDP). 114 The SCTP association is created with the number of streams specified 115 by the application, and if not specified, then it SHOULD default to 116 16 streams. 118 It is recommended that additional streams be available dynamically 119 based on [RFC6525]. 121 5. Control Messages 123 Data Channel Control Messages are sent to manage opening 124 bidirectional channels. A DATA_CHANNEL_OPEN_REQUEST message is sent 125 on the Stream that is intended to be used to send in that direction, 126 and a response (DATA_CHANNEL_OPEN_RESPONSE) is sent back on the 127 Stream to be used for the other direction, with a 128 reverse_direction_stream entry holding the Stream number the 129 DATA_CHANNEL_OPEN_REQUEST was sent on. This allows association of 130 the Streams that define the bidirectional channel. Finally, a 131 DATA_CHANNEL_ACK is sent on the original Stream to complete the 3-way 132 handshake. 134 Errors are returned by setting the error field of the 135 DATA_CHANNEL_OPEN_RESPONSE message to a non-0 value. In this case 136 the original sender of DATA_CHANNEL_OPEN_REQUEST shall close the 137 channel. 139 5.1. DATA_CHANNEL_OPEN_REQUEST Message 141 This message is sent initially on the stream used for user messages 142 using the channel. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Message Type | Channel Type | Flags | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Reliability Parameter | Priority | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 \ / 152 | Label | 153 / \ 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Message Type: 1 byte (unsigned integer) 157 This field holds the IANA defined message type for the the 158 DATA_CHANNEL_OPEN_REQUEST message. The suggested value of this 159 field for IANA is 0x00. 160 Channel Type: 1 byte (unsigned integer) 161 This field specifies the type of the channel to be opened: 162 DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable bi- 163 directional communication channel. 164 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides 165 a partial reliable bi-directional Communication channel. User 166 messages will not be retransmitted more times than specified in 167 the Reliability Parameter. 169 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides 170 a partial reliable bi-directional Communication channel. User 171 messages might not be transmitted or retransmitted after a 172 specified life-time given in milli-seconds in the Reliability 173 Parameter. This life-time starts when providing the user 174 message to the Javascript engine. 175 Flags: 2 bytes (unsigned integer) 176 This field contains the bitwise OR of the following flags: 177 DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED (0x0001): If this flag is 178 set, the channel does not need to preserve the message 179 sequencing. 180 Reliability Parameter: 2 bytes (unsigned integer) 181 This field is ignored if a reliable channel is used. If a partial 182 reliable channel with limited number of retransmissions is used, 183 this field specifies the number of retransmissions. If a partial 184 reliable channel with limited lifetime is used, this field 185 specifies the maximum life-time in milli seconds. 186 Priority: 2 bytes (integer) 187 The priority of the channel. 188 Label: Variable Length (sequence of characters) 189 The name of the channel in UTF-8, including a trailing '\0' byte. 191 5.2. DATA_CHANNEL_OPEN_RESPONSE Message 193 This message is sent in response to an DATA_CHANNEL_OPEN_REQUEST 194 message on the stream used for user messages using the channel. 195 Messages with the error field set to non-0 values can be sent on any 196 stream; it is suggested that they be sent (if possible) on an unused 197 stream. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Message Type | Error | Flags | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Reverse Stream | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Message Type: 1 byte (unsigned integer) 208 This field holds the IANA defined message type for the the 209 DATA_CHANNEL_OPEN_RESPONSE message. The suggested value of this 210 field for IANA is 0x01. 211 Error: 1 byte (unsigned integer) 212 TBD. 214 Flags: 2 bytes (unsigned integer) 215 TBD. 216 Reverse Stream: 2 bytes (unsigned integer) 217 The identifier for the incoming stream of the channel. The 218 corresponding DATA_CHANNEL_OPEN_REQUEST message was received on 219 this stream. 221 5.3. DATA_CHANNEL_ACK Message 223 This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE 224 message on the stream used for user messages using the channel. 225 Reception of this message tells the opener that the channel setup 226 handshake is complete. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Message Type | 232 +-+-+-+-+-+-+-+-+ 234 Message Type: 1 byte (unsigned integer) 235 This field holds the IANA defined message type for the the 236 DATA_CHANNEL_ACK message. The suggested value of this field for 237 IANA is 0x02. 239 6. Procedures 241 6.1. Adding a Channel 243 When one side wants to add a channel, it picks an unused outgoing 244 stream; if no unused streams are available a negotiation to increase 245 the number is done. It then sends a DATA_CHANNEL_OPEN_REQUEST 246 control message on the outgoing stream. 248 The channel_type and reliability_parameters fields of an incoming 249 DATA_CHANNEL_OPEN_REQUEST message MUST be used to set up the reverse 250 stream for the Data Channel so that both directions use the same 251 options. So both directions are either reliable or use the PR-SCTP 252 extension defined in [RFC3758] using the same policy and parameter. 254 When an DATA_CHANNEL_OPEN_REQUEST is received on an incoming stream, 255 an unused outgoing stream is picked; if no unused streams are 256 available a negotiation to increase the number is done. A 257 DATA_CHANNEL_OPEN_RESPONSE message is sent on the outgoing stream, 258 with the Reverse Stream field set to the incoming stream the 259 DATA_CHANNEL_OPEN_REQUEST message came in on. If for any reason the 260 entity receiving the DATA_CHANNEL_OPEN_REQUEST can't open the 261 channel, then it should respond with an DATA_CHANNEL_OPEN_RESPONSE 262 with an error value set. Any stream can be used for the 263 DATA_CHANNEL_OPEN_RESPONSE, but it is recommended that the message be 264 sent any unused-but-available-stream, and if none are available it 265 may be sent on any stream. 267 When a DATA_CHANNEL_OPEN_RESPONSE is received, the Reverse Stream 268 value is matched against all pending DATA_CHANNEL_OPEN_REQUEST 269 messages. If no match can be found, the DATA_CHANNEL_OPEN_RESPONSE 270 message SHOULD be ignored. If a match is found, then if the error 271 value is 0 a DATA_CHANNEL_ACK message is sent on the originator's 272 outgoing Stream for the channel. If the error value is non-zero, the 273 open failed, and the originator SHOULD close down the originally- 274 selected outgoing stream and notify the application. 276 6.2. Closing a Channel 278 Data Channels shall be closed by resetting the outgoing stream If an 279 incoming stream is reset by the peer, an corresponding outgoing 280 stream reset SHOULD be issued. If both streams of a channel are 281 reset, the channel is closed and the streams are available for reuse 282 for new channel opens. 284 6.3. Sending and Receiving Data 286 Data shall be sent using PPID's other than the Data Channel Control 287 PPID. These PPID's should be registered with IANA via (TBD). The 288 meaning of these data PPIDs and the format of the data shall be 289 specific to the usage of this protocol, and typically shall be 290 provided to the higher layers to allow proper decoding of the data. 292 For WebRTC, data PPID's for DOMStrings and binary data blobs shall be 293 created. 295 All data sent on a Data Channel in both directions MUST be sent over 296 the underlying Stream using the reliability defined when the Data 297 Channel was opened. 299 Data may be sent before the 3-way handshake is complete; if so it 300 must be sent with in-order delivery set in order to avoid race 301 conditions cause by a handshake message being lost. This is an 302 exception to the requirement to send all data using the channel 303 reliability settings. 305 6.3.1. Message Length 307 The maximum size for messages in this protocol is 2GB (0x7FFFFFF 308 bytes). In order to avoid blocking all other streams while sending a 309 large message, a TBD extension to SCTP is required. [If that draft 310 does not become available, in-protocol chunking of the data would be 311 required, either using in-packet framing or multiple PPIDs.] 313 In order for code using this protocol to be compatible with an 314 alternate transport over WebSockets, it is recommended that string 315 message size be kept within certain bounds. WebSockets mandates a 316 maximum length for UTF-8 string Send()s of 123 characters. If 317 transport over WebSockets is not envisioned, then the limitation is 318 moot. 320 7. Signaling 322 This is an application protocol that will normally run on top of 323 SCTP. In the case of rtcweb, it will run over SCTP/DTLS (SCTP on top 324 of DTLS). This protocol should be specified in the section of 325 the m=application SDP line (Figure 1), details TBD (see 326 [I-D.ietf-mmusic-sctp-sdp]). The section should include the 327 virtual port over the rtcweb DataChannel's SCTP association runs on. 328 (This would allow for more than one association to be used on a DTLS 329 connection; it's an open question if this flexibility is needed.) 331 An a=fmtp line will be used to specify that this protocol is to be 332 used, and any options. Options would include the number of streams 333 (streams=N), and may include pre-definitions of data channels to be 334 opened as soon as the association is available. 336 m=application SCTP/DTLS 337 a=fmtp: protocol=webrtc-datachannel;streams=32 339 Figure 1: Data Channel SDP media line 341 7.1. Startup considerations 343 It has been suggested that in order to speed up channel creation that 344 an initial set of channels be allowed to be specified in the SDP, as 345 a very common case for applications will be a fixed set of data 346 channels. This SDP format would support that: (line split for 347 readability) 349 m=application SCTP/DTLS 350 a=fmtp: protocol=webrtc-datachannel;streams=32; 351 stream=0;type=0;name="foo"; 352 stream=1;type=1;max-rexmit=4;inorder;name="bar"; 353 stream=2;type=2;max-rexmit-time=400;name="timed 400ms max" 355 Figure 2: Data Channel SDP media plus channels 357 The answer would echo the channel definitions from the offer, with 358 the associated stream numbers to associated with the channel. This 359 would mean that the data channels would be available to use as soon 360 as the association has been negotiated. 362 This may need to be specified via MMUSIC. 364 8. Security Considerations 366 To be done. 368 9. IANA Considerations 370 This document also defines three new SCTP Payload Protocol 371 Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from 372 which these identifiers have been assigned. The following values 373 have been reserved: 374 WebRTC Control - #To Be Assigned 375 DOMString - #To Be Assigned 376 Binary Data - #To Be Assigned 378 10. Acknowledgments 380 The authors wish to thank Cullen Jennings, Adam Berquist, Justin 381 Uberti, Randall Stewart, ... for there invaluable comments. 383 11. References 385 11.1. Normative References 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, March 1997. 390 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 391 Conrad, "Stream Control Transmission Protocol (SCTP) 392 Partial Reliability Extension", RFC 3758, May 2004. 394 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 395 RFC 4960, September 2007. 397 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 398 Security Version 1.2", RFC 6347, January 2012. 400 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 401 Transmission Protocol (SCTP) Stream Reconfiguration", 402 RFC 6525, February 2012. 404 [I-D.ietf-mmusic-sctp-sdp] 405 Loreto, S. and G. Camarillo, "Stream Control Transmission 406 Protocol (SCTP)-Based Media Transport in the Session 407 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-01 408 (work in progress), March 2012. 410 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 411 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 412 Encapsulation of SCTP Packets for RTCWEB", 413 draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress), 414 July 2012. 416 11.2. Informational References 418 [I-D.ietf-rtcweb-overview] 419 Alvestrand, H., "Overview: Real Time Protocols for Brower- 420 based Applications", draft-ietf-rtcweb-overview-04 (work 421 in progress), June 2012. 423 [I-D.ietf-rtcweb-data-channel] 424 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram 425 Connection", draft-ietf-rtcweb-data-channel-00 (work in 426 progress), March 2012. 428 Authors' Addresses 430 Randell Jesup 431 Mozilla 432 US 434 Email: randell-ietf@jesup.org 436 Salvatore Loreto 437 Ericsson 438 Hirsalantie 11 439 Jorvas 02420 440 FI 442 Email: salvatore.loreto@ericsson.com 443 Michael Tuexen 444 Muenster University of Applied Sciences 445 Stegerwaldstrasse 39 446 Steinfurt 48565 447 DE 449 Email: tuexen@fh-muenster.de