idnits 2.17.1 draft-jesup-rtcweb-data-protocol-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 (June 9, 2012) is 4338 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 (-01) exists of draft-tuexen-tsvwg-sctp-dtls-encaps-00 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-00 Summary: 2 errors (**), 0 flaws (~~), 5 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: December 11, 2012 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 June 9, 2012 10 WebRTC Data Channel Protocol 11 draft-jesup-rtcweb-data-protocol-01.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 December 11, 2012. 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. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 10.2. Informational References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The Data Channel Protocol is designed to provide, in the WebRTC 79 context [I-D.ietf-rtcweb-overview], a generic transport service 80 allowing Web Browser to exchange generic data in a bidirectional peer 81 to peer fashion. As discussed in [I-D.ietf-rtcweb-data-channel] the 82 protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960] 83 encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] as 84 described in [I-D.tuexen-tsvwg-sctp-dtls-encaps] to benefit from 85 their already standardized transport and security features. 87 2. Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Terminology 95 This document uses the following terms: 96 Association: An SCTP association. 97 Stream: A unidirectional stream of an SCTP association. It is 98 uniquely identified by a stream identifier. 99 Channel: A bidirectional channel consisting of two SCTP streams. 101 4. Opening Handshake 103 The opening handshake is based on the multimedia session description 104 exchange that happens between the browsers, typically through a Web 105 Server acting as the signaling service. 107 [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'SCTP/ 108 DTLS', and defines how to establish an SCTP association over DTLS 109 using the Session Description Protocol (SDP). 111 The SCTP association is created with the number of streams specified 112 by the application, and if not specified, then it SHOULD default to 113 16 streams. 115 It is recommended that additional streams be available dynamically 116 based on [RFC6525]. 118 5. Control Messages 120 Data Channel Control Messages are sent to manage opening 121 bidirectional channels. A DATA_CHANNEL_OPEN_REQUEST message is sent 122 on the Stream that is intended to be used to send in that direction, 123 and a response (DATA_CHANNEL_OPEN_RESPONSE) is sent back on the 124 Stream to be used for the other direction, with a 125 reverse_direction_stream entry holding the Stream number the 126 DATA_CHANNEL_OPEN_REQUEST was sent on. This allows association of 127 the Streams that define the bidirectional channel. Finally, a 128 DATA_CHANNEL_ACK is sent on the original Stream to complete the 3-way 129 handshake. 131 Errors are returned by setting the error field of the 132 DATA_CHANNEL_OPEN_RESPONSE message to a non-0 value. In this case 133 the original sender of DATA_CHANNEL_OPEN_REQUEST shall close the 134 channel. 136 5.1. DATA_CHANNEL_OPEN_REQUEST Message 138 This message is sent initially on the stream used for user messages 139 using the channel. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Message Type | Channel Type | Flags | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Reliability Parameter | Priority | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 \ / 149 | Label | 150 / \ 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Message Type: 1 byte (unsigned integer) 154 This field holds the IANA defined message type for the the 155 DATA_CHANNEL_OPEN_REQUEST message. The suggested value of this 156 field for IANA is 0x00. 157 Channel Type: 1 byte (unsigned integer) 158 This field specifies the type of the channel to be opened: 159 DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable bi- 160 directional communication channel. 161 DATA_CHANNEL_RELIABLE_STREAM (0x01): TBD. 163 DATA_CHANNEL_UNRELIABLE (0x02): TBD. 164 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x03): 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. 168 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x04): The channel provides 169 a partial reliable bi-directional Communication channel. User 170 messages might not be transmitted or retransmitted after a 171 specified life-time given in milli-seconds in the Reliability 172 Parameter. This life-time starts when providing the user 173 message to the Javascript engine. 174 Flags: 2 bytes (unsigned integer) 175 This field contains the bitwise OR of the following flags: 176 DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED (0x0001): If this flag is 177 set, the channel does not need to preserve the message 178 sequencing. 179 Reliability Parameter: 2 bytes (unsigned integer) 180 This field is ignored if a reliable channel is used. If a partial 181 reliable channel with limited number of retransmissions is used, 182 this field specifies the number of retransmissions. If a partial 183 reliable channel with limited lifetime is used, this field 184 specifies the maximum life-time in milli seconds. 185 Priority: 2 bytes (integer) 186 The priority of the channel. 187 Label: Variable Length (sequence of characters) 188 The name of the channel. 190 5.2. DATA_CHANNEL_OPEN_RESPONSE Message 192 This message is sent in response to an DATA_CHANNEL_OPEN_REQUEST 193 message on the stream used for user messages using the channel. 194 Messages with the error field set to non-0 values can be sent on any 195 stream; it is suggested that they be sent (if possible) on an unused 196 stream. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Message Type | Error | Flags | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Reverse Stream | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Message Type: 1 byte (unsigned integer) 207 This field holds the IANA defined message type for the the 208 DATA_CHANNEL_OPEN_RESPONSE message. The suggested value of this 209 field for IANA is 0x01. 211 Error: 1 byte (unsigned integer) 212 TBD. 213 Flags: 2 bytes (unsigned integer) 214 TBD. 215 Reverse Stream: 2 bytes (unsigned integer) 216 The identifier for the incoming stream of the channel. The 217 corresponding DATA_CHANNEL_OPEN_REQUEST message was received on 218 this stream. 220 5.3. DATA_CHANNEL_ACK Message 222 This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE 223 message on the stream used for user messages using the channel. 224 Reception of this message tells the opener that the channel setup 225 handshake is complete. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Message Type | 231 +-+-+-+-+-+-+-+-+ 233 Message Type: 1 byte (unsigned integer) 234 This field holds the IANA defined message type for the the 235 DATA_CHANNEL_ACK message. The suggested value of this field for 236 IANA is 0x02. 238 6. Procedures 240 6.1. Adding a Channel 242 When one side wants to add a channel, it picks an unused outgoing 243 stream; if no unused streams are available a negotiation to increase 244 the number is done. It then sends a DATA_CHANNEL_OPEN_REQUEST 245 control message on the outgoing stream. 247 When an DATA_CHANNEL_OPEN_REQUEST is received on an incoming stream, 248 an unused outgoing stream is picked; if no unused streams are 249 available a negotiation to increase the number is done. A 250 DATA_CHANNEL_OPEN_RESPONSE message is sent on the outgoing stream, 251 with the Reverse Stream field set to the incoming stream the 252 DATA_CHANNEL_OPEN_REQUEST message came in on. 254 When a DATA_CHANNEL_OPEN_RESPONSE is received, the Reverse Stream 255 value is matched against all pending DATA_CHANNEL_OPEN_REQUEST 256 messages. If no match can be found, the DATA_CHANNEL_OPEN_RESPONSE 257 message SHOULD be ignored. If a match is found, then if the error 258 value is 0 a DATA_CHANNEL_ACK message is sent on the originator's 259 outgoing Stream for the channel. If the error value is non-zero, the 260 open failed, and the originator SHOULD close down the originally- 261 selected outgoing stream and notify the application. 263 The channel_type and reliability_parameters fields of the 264 DATA_CHANNEL_OPEN_REQUEST message MUST be used to set up the reverse 265 side of the Data Channel so that both directions use the same 266 options. So both directions are either reliable or use the PR-SCTP 267 extension defined in [RFC3758] using the same policy and parameter. 269 6.2. Closing a Channel 271 Data Channels shall be closed by resetting the outgoing stream If an 272 incoming stream is reset by the peer, an corresponding outgoing 273 stream reset SHOULD be issued. If both streams of a channel are 274 reset, the channel is closed and the streams are available for reuse 275 for new channel opens. 277 6.3. Sending and Receiving Data 279 Data shall be sent using PPID's other than the Data Channel Control 280 PPID. These PPID's should be registered with IANA via (TBD). The 281 meaning of these data PPIDs and the format of the data shall be 282 specific to the usage of this protocol, and typically shall be 283 provided to the higher layers to allow proper decoding of the data. 285 For WebRTC, data PPID's for DOMStrings and binary data blobs shall be 286 created. 288 All data sent on a Data Channel in both directions MUST be sent over 289 the underlying Stream using the reliability defined when the Data 290 Channel was opened. 292 Data may be sent before the 3-way handshake is complete; if so it 293 must be sent with in-order delivery set in order to avoid race 294 conditions cause by a handshake message being lost. This is an 295 exception to the requirement to send all data using the channel 296 reliability settings. 298 It is recommended that message size be kept within certain bounds 299 (TBD). 301 7. Security Considerations 303 To be done. 305 8. IANA Considerations 307 This document also defines three new SCTP Payload Protocol 308 Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from 309 which these identifiers have been assigned. The following values 310 have been reserved: 311 WebRTC Control - #To Be Assigned 312 DOMString - #To Be Assigned 313 Binary Data - #To Be Assigned 315 9. Acknowledgments 317 The authors wish to thank ... for there invaluable comments. 319 10. References 321 10.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 327 Conrad, "Stream Control Transmission Protocol (SCTP) 328 Partial Reliability Extension", RFC 3758, May 2004. 330 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 331 RFC 4960, September 2007. 333 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 334 Security Version 1.2", RFC 6347, January 2012. 336 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 337 Transmission Protocol (SCTP) Stream Reconfiguration", 338 RFC 6525, February 2012. 340 [I-D.ietf-mmusic-sctp-sdp] 341 Loreto, S. and G. Camarillo, "Stream Control Transmission 342 Protocol (SCTP)-Based Media Transport in the Session 343 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-01 344 (work in progress), March 2012. 346 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 347 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 348 Encapsulation of SCTP Packets for RTCWEB", 349 draft-tuexen-tsvwg-sctp-dtls-encaps-00 (work in progress), 350 March 2012. 352 10.2. Informational References 354 [I-D.ietf-rtcweb-overview] 355 Alvestrand, H., "Overview: Real Time Protocols for Brower- 356 based Applications", draft-ietf-rtcweb-overview-03 (work 357 in progress), March 2012. 359 [I-D.ietf-rtcweb-data-channel] 360 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram 361 Connection", draft-ietf-rtcweb-data-channel-00 (work in 362 progress), March 2012. 364 Authors' Addresses 366 Randell Jesup 367 Mozilla 368 US 370 Email: randell-ietf@jesup.org 372 Salvatore Loreto 373 Ericsson 374 Hirsalantie 11 375 Jorvas 02420 376 FI 378 Email: salvatore.loreto@ericsson.com 380 Michael Tuexen 381 Muenster University of Applied Sciences 382 Stegerwaldstrasse 39 383 Steinfurt 48565 384 DE 386 Email: tuexen@fh-muenster.de