idnits 2.17.1 draft-jesup-rtcweb-data-protocol-02.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 16, 2012) is 4294 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: January 17, 2013 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 July 16, 2012 10 WebRTC Data Channel Protocol 11 draft-jesup-rtcweb-data-protocol-02.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 January 17, 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 7. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Startup considerations . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 11.2. Informational References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The Data Channel Protocol is designed to provide, in the WebRTC 81 context [I-D.ietf-rtcweb-overview], a generic transport service 82 allowing Web Browser to exchange generic data in a bidirectional peer 83 to peer fashion. As discussed in [I-D.ietf-rtcweb-data-channel] the 84 protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960] 85 encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] as 86 described in [I-D.tuexen-tsvwg-sctp-dtls-encaps] to benefit from 87 their already standardized transport and security features. 89 2. Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. Terminology 97 This document uses the following terms: 98 Association: An SCTP association. 99 Stream: A unidirectional stream of an SCTP association. It is 100 uniquely identified by a stream identifier. 101 Channel: A bidirectional channel consisting of two SCTP streams. 103 4. Opening Handshake 105 The opening handshake is based on the multimedia session description 106 exchange that happens between the browsers, typically through a Web 107 Server acting as the signaling service. 109 [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'SCTP/ 110 DTLS', and defines how to establish an SCTP association over DTLS 111 using the Session Description Protocol (SDP). 113 The SCTP association is created with the number of streams specified 114 by the application, and if not specified, then it SHOULD default to 115 16 streams. 117 It is recommended that additional streams be available dynamically 118 based on [RFC6525]. 120 5. Control Messages 122 Data Channel Control Messages are sent to manage opening 123 bidirectional channels. A DATA_CHANNEL_OPEN_REQUEST message is sent 124 on the Stream that is intended to be used to send in that direction, 125 and a response (DATA_CHANNEL_OPEN_RESPONSE) is sent back on the 126 Stream to be used for the other direction, with a 127 reverse_direction_stream entry holding the Stream number the 128 DATA_CHANNEL_OPEN_REQUEST was sent on. This allows association of 129 the Streams that define the bidirectional channel. Finally, a 130 DATA_CHANNEL_ACK is sent on the original Stream to complete the 3-way 131 handshake. 133 Errors are returned by setting the error field of the 134 DATA_CHANNEL_OPEN_RESPONSE message to a non-0 value. In this case 135 the original sender of DATA_CHANNEL_OPEN_REQUEST shall close the 136 channel. 138 5.1. DATA_CHANNEL_OPEN_REQUEST Message 140 This message is sent initially on the stream used for user messages 141 using the channel. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Message Type | Channel Type | Flags | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Reliability Parameter | Priority | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 \ / 151 | Label | 152 / \ 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Message Type: 1 byte (unsigned integer) 156 This field holds the IANA defined message type for the the 157 DATA_CHANNEL_OPEN_REQUEST message. The suggested value of this 158 field for IANA is 0x00. 159 Channel Type: 1 byte (unsigned integer) 160 This field specifies the type of the channel to be opened: 161 DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable bi- 162 directional communication channel. 163 DATA_CHANNEL_RELIABLE_STREAM (0x01): TBD. 165 DATA_CHANNEL_UNRELIABLE (0x02): TBD. 166 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x03): The channel provides 167 a partial reliable bi-directional Communication channel. User 168 messages will not be retransmitted more times than specified in 169 the Reliability Parameter. 170 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x04): The channel provides 171 a partial reliable bi-directional Communication channel. User 172 messages might not be transmitted or retransmitted after a 173 specified life-time given in milli-seconds in the Reliability 174 Parameter. This life-time starts when providing the user 175 message to the Javascript engine. 176 Flags: 2 bytes (unsigned integer) 177 This field contains the bitwise OR of the following flags: 178 DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED (0x0001): If this flag is 179 set, the channel does not need to preserve the message 180 sequencing. 181 Reliability Parameter: 2 bytes (unsigned integer) 182 This field is ignored if a reliable channel is used. If a partial 183 reliable channel with limited number of retransmissions is used, 184 this field specifies the number of retransmissions. If a partial 185 reliable channel with limited lifetime is used, this field 186 specifies the maximum life-time in milli seconds. 187 Priority: 2 bytes (integer) 188 The priority of the channel. 189 Label: Variable Length (sequence of characters) 190 The name of the channel. 192 5.2. DATA_CHANNEL_OPEN_RESPONSE Message 194 This message is sent in response to an DATA_CHANNEL_OPEN_REQUEST 195 message on the stream used for user messages using the channel. 196 Messages with the error field set to non-0 values can be sent on any 197 stream; it is suggested that they be sent (if possible) on an unused 198 stream. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Message Type | Error | Flags | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reverse Stream | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Message Type: 1 byte (unsigned integer) 209 This field holds the IANA defined message type for the the 210 DATA_CHANNEL_OPEN_RESPONSE message. The suggested value of this 211 field for IANA is 0x01. 213 Error: 1 byte (unsigned integer) 214 TBD. 215 Flags: 2 bytes (unsigned integer) 216 TBD. 217 Reverse Stream: 2 bytes (unsigned integer) 218 The identifier for the incoming stream of the channel. The 219 corresponding DATA_CHANNEL_OPEN_REQUEST message was received on 220 this stream. 222 5.3. DATA_CHANNEL_ACK Message 224 This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE 225 message on the stream used for user messages using the channel. 226 Reception of this message tells the opener that the channel setup 227 handshake is complete. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Message Type | 233 +-+-+-+-+-+-+-+-+ 235 Message Type: 1 byte (unsigned integer) 236 This field holds the IANA defined message type for the the 237 DATA_CHANNEL_ACK message. The suggested value of this field for 238 IANA is 0x02. 240 6. Procedures 242 6.1. Adding a Channel 244 When one side wants to add a channel, it picks an unused outgoing 245 stream; if no unused streams are available a negotiation to increase 246 the number is done. It then sends a DATA_CHANNEL_OPEN_REQUEST 247 control message on the outgoing stream. 249 When an DATA_CHANNEL_OPEN_REQUEST is received on an incoming stream, 250 an unused outgoing stream is picked; if no unused streams are 251 available a negotiation to increase the number is done. A 252 DATA_CHANNEL_OPEN_RESPONSE message is sent on the outgoing stream, 253 with the Reverse Stream field set to the incoming stream the 254 DATA_CHANNEL_OPEN_REQUEST message came in on. 256 When a DATA_CHANNEL_OPEN_RESPONSE is received, the Reverse Stream 257 value is matched against all pending DATA_CHANNEL_OPEN_REQUEST 258 messages. If no match can be found, the DATA_CHANNEL_OPEN_RESPONSE 259 message SHOULD be ignored. If a match is found, then if the error 260 value is 0 a DATA_CHANNEL_ACK message is sent on the originator's 261 outgoing Stream for the channel. If the error value is non-zero, the 262 open failed, and the originator SHOULD close down the originally- 263 selected outgoing stream and notify the application. 265 The channel_type and reliability_parameters fields of the 266 DATA_CHANNEL_OPEN_REQUEST message MUST be used to set up the reverse 267 side of the Data Channel so that both directions use the same 268 options. So both directions are either reliable or use the PR-SCTP 269 extension defined in [RFC3758] using the same policy and parameter. 271 6.2. Closing a Channel 273 Data Channels shall be closed by resetting the outgoing stream If an 274 incoming stream is reset by the peer, an corresponding outgoing 275 stream reset SHOULD be issued. If both streams of a channel are 276 reset, the channel is closed and the streams are available for reuse 277 for new channel opens. 279 6.3. Sending and Receiving Data 281 Data shall be sent using PPID's other than the Data Channel Control 282 PPID. These PPID's should be registered with IANA via (TBD). The 283 meaning of these data PPIDs and the format of the data shall be 284 specific to the usage of this protocol, and typically shall be 285 provided to the higher layers to allow proper decoding of the data. 287 For WebRTC, data PPID's for DOMStrings and binary data blobs shall be 288 created. 290 All data sent on a Data Channel in both directions MUST be sent over 291 the underlying Stream using the reliability defined when the Data 292 Channel was opened. 294 Data may be sent before the 3-way handshake is complete; if so it 295 must be sent with in-order delivery set in order to avoid race 296 conditions cause by a handshake message being lost. This is an 297 exception to the requirement to send all data using the channel 298 reliability settings. 300 It is recommended that message size be kept within certain bounds 301 (TBD). 303 7. Signaling 305 This is an application protocol that will normally run on top of 306 SCTP. In the case of rtcweb, it will run over SCTP/DTLS (SCTP on top 307 of DTLS). This protocol should be specified in the section of 308 the m=application SDP line (Figure 1), details TBD. The 309 section should include the virtual port over the rtcweb DataChannel's 310 SCTP association runs on. (This would allow for more than one 311 association to be used on a DTLS connection; it's an open question if 312 this flexibility is needed.) 314 m=application SCTP/DTLS 316 Figure 1: Data Channel SDP media line 318 7.1. Startup considerations 320 It has been suggested that in order to speed up channel creation that 321 an initial set of channels be allowed to be specified in the SDP, as 322 a very common case for applications will be a fixed set of data 323 channels. This SDP format would support that: 325 m=application SCTP/DTLS 326 a=fmtp:0 channel=1;stream=0;type=reliable;name="foo" 327 a=fmtp:1 channel=2;stream=1;type=unreliable;inorder;name="bar" 329 Figure 2: Data Channel SDP media plus channels 331 The answer would echo the channel definitions from the offer, with 332 the associated stream numbers to associated with the channel. This 333 would mean that the data channels would be available to use as soon 334 as the association has been negotiated. 336 This may need to be specified via MMUSIC. 338 8. Security Considerations 340 To be done. 342 9. IANA Considerations 344 This document also defines three new SCTP Payload Protocol 345 Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from 346 which these identifiers have been assigned. The following values 347 have been reserved: 348 WebRTC Control - #To Be Assigned 349 DOMString - #To Be Assigned 350 Binary Data - #To Be Assigned 352 10. Acknowledgments 354 The authors wish to thank Cullen Jennings, Adam Berquist, Justin 355 Uberti, Randall Stewart, ... for there invaluable comments. 357 11. References 359 11.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 365 Conrad, "Stream Control Transmission Protocol (SCTP) 366 Partial Reliability Extension", RFC 3758, May 2004. 368 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 369 RFC 4960, September 2007. 371 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 372 Security Version 1.2", RFC 6347, January 2012. 374 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 375 Transmission Protocol (SCTP) Stream Reconfiguration", 376 RFC 6525, February 2012. 378 [I-D.ietf-mmusic-sctp-sdp] 379 Loreto, S. and G. Camarillo, "Stream Control Transmission 380 Protocol (SCTP)-Based Media Transport in the Session 381 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-01 382 (work in progress), March 2012. 384 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 385 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 386 Encapsulation of SCTP Packets for RTCWEB", 387 draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress), 388 July 2012. 390 11.2. Informational References 392 [I-D.ietf-rtcweb-overview] 393 Alvestrand, H., "Overview: Real Time Protocols for Brower- 394 based Applications", draft-ietf-rtcweb-overview-04 (work 395 in progress), June 2012. 397 [I-D.ietf-rtcweb-data-channel] 398 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram 399 Connection", draft-ietf-rtcweb-data-channel-00 (work in 400 progress), March 2012. 402 Authors' Addresses 404 Randell Jesup 405 Mozilla 406 US 408 Email: randell-ietf@jesup.org 410 Salvatore Loreto 411 Ericsson 412 Hirsalantie 11 413 Jorvas 02420 414 FI 416 Email: salvatore.loreto@ericsson.com 418 Michael Tuexen 419 Muenster University of Applied Sciences 420 Stegerwaldstrasse 39 421 Steinfurt 48565 422 DE 424 Email: tuexen@fh-muenster.de