idnits 2.17.1 draft-jesup-rtcweb-data-protocol-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 (February 26, 2013) is 4070 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) == Unused Reference: 'RFC3758' is defined on line 327, but no explicit reference was found in the text ** 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-03 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-03 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: August 30, 2013 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 February 26, 2013 10 WebRTC Data Channel Protocol 11 draft-jesup-rtcweb-data-protocol-04.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 August 30, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . . 4 63 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Adding a Channel . . . . . . . . . . . . . . . . . . . . . 6 65 7.2. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 7 66 7.3. Sending and Receiving Data . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 11.2. Informational References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The DataChannel Protocol is designed to provide, in the WebRTC 78 context [I-D.ietf-rtcweb-overview], a generic transport service 79 allowing Web Browser to exchange generic data in a bidirectional peer 80 to peer fashion. As discussed in [I-D.ietf-rtcweb-data-channel] the 81 protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960] 82 encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] as 83 described in [I-D.tuexen-tsvwg-sctp-dtls-encaps] to benefit from 84 their already standardized transport and security features. 86 2. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Terminology 94 This document uses the following terms: 95 Association: An SCTP association. 96 Stream: A unidirectional stream of an SCTP association. It is 97 uniquely identified by a stream identifier. 98 Channel: Two Streams with the same identifier, one in each 99 direction, that are managed together. 101 4. Protocol Overview 103 This protocol is a simple, low-overhead way to establish 104 bidirectional Channels over an SCTP association with a consistent set 105 of properties. 107 Channels are created by sending an DATA_CHANNEL_OPEN message on an 108 unused Stream. There is no handshake, and the channel is available 109 to send on as soon as the DATA_CHANNEL_OPEN has been sent. 111 To avoid glare in opening Channels, each side must use either even or 112 odd Streams when sending a DATA_CHANNEL_OPEN message. The method 113 used to determine which side uses odd or even is TBD and may be based 114 on DTLS connection roles when used in rtcweb. 116 There is no attempt to resolve label glare; if both sides open a 117 Channel labelled "x" at the same time, there will be two Channels 118 labelled "x" - one on an even Stream pair, one on an odd pair. 120 The protocol field is to ease cross-application interoperation 121 ("federation") by identifying the data being passed with an IANA- 122 registered string. 124 Data that arrives which on an unused Stream MUST be held until a 125 DATA_CHANNEL_OPEN arrived for that Channel, or if the protocol stack 126 had been told to expect data on that Stream and deliver it 127 immediately, or until [TBD - report error]. This allows for external 128 negotiation of streams (or assumption of negotiation by cooperating 129 applications). If a later DATA_CHANNEL_OPEN arrives that conflicts 130 with the pre-set properties of the Channel, an error should be 131 signaled to higher levels. 133 Channels are closed by resetting the Stream. 135 5. Opening Handshake 137 The opening handshake is based on the multimedia session description 138 exchange that happens between the browsers, typically through a Web 139 Server acting as the signaling service. 141 [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'SCTP/ 142 DTLS', and defines how to establish an SCTP association over DTLS 143 using the Session Description Protocol (SDP). 145 The SCTP association is created with the number of streams specified 146 by the application, and if not specified, then it SHOULD default to 147 16 streams. 149 It is recommended that additional streams be available dynamically 150 based on [RFC6525]. 152 6. Control Messages 154 Control Messages are sent to manage opening bidirectional channels. 156 A DATA_CHANNEL_OPEN message is sent on the Stream that is intended to 157 be used to send in that direction, and this creates a bidirectional 158 Channel that may be used by both sides to send data. 160 6.1. DATA_CHANNEL_OPEN Message 162 This message is sent initially on the stream used for user messages 163 using the channel. All DATA_CHANNEL_OPEN messages MUST be sent 164 reliably and in-order. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Message Type | Channel Type | Reliability Parameter | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Priority r | Label Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Protocol Length | / 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 175 \ | 176 | Label | 177 / \ 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 \ / 180 | Protocol | 181 / \ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Message Type: 1 byte (unsigned integer) 185 This field holds the IANA defined message type for the the 186 DATA_CHANNEL_OPEN message. The suggested value of this field for 187 IANA is 0x03. NOTE: values 0x00-0x02 were used in an older draft 188 with incompatible structures. Any future incompatible message 189 changes should define new message types. 190 Channel Type: 1 byte (unsigned integer) 191 This field specifies the type of the channel to be opened: 192 DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable in- 193 order bi-directional communication channel. 194 DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a 195 reliable unordered bi-directional communication channel. 196 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides 197 a partially-reliable in-order bi-directional Communication 198 channel. User messages will not be retransmitted more times 199 than specified in the Reliability Parameter. 200 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The 201 channel provides a partial reliable unordered bi-directional 202 Communication channel. User messages will not be retransmitted 203 more times than specified in the Reliability Parameter. 204 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides 205 a partial reliable in-order bi-directional Communication 206 channel. User messages might not be transmitted or 207 retransmitted after a specified life-time given in milli- 208 seconds in the Reliability Parameter. This life-time starts 209 when providing the user message to the Javascript engine. 211 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x82): The channel provides 212 a partial reliable unordered bi-directional Communication 213 channel. User messages might not be transmitted or 214 retransmitted after a specified life-time given in milli- 215 seconds in the Reliability Parameter. This life-time starts 216 when providing the user message to the Javascript engine. 217 Reliability Parameter: 2 bytes (unsigned integer) 218 This field is ignored if a reliable channel is used. 219 If a partial reliable channel with limited number of 220 retransmissions is used, this field specifies the number of 221 retransmissions. If a partial reliable channel with limited 222 lifetime is used, this field specifies the maximum lifetime in 223 milliseconds. 224 Priority: 2 bytes (integer) 225 The priority of the channel. 226 Label Length: 2 bytes (integer) 227 The length of the label field in bytes. 228 Protocol Length: 2 bytes (integer) 229 The length of the protocol field in bytes. 230 Label: Variable Length (sequence of characters) 231 The name of the channel. This may be an empty string. 232 Protocol: Variable Length (sequence of characters) 233 The protocol for the channel. This may be an empty string. If 234 used, it SHOULD be an IANA-registered protocol. 236 7. Procedures 238 7.1. Adding a Channel 240 When one side wants to add a channel, it picks an unused outgoing 241 stream (either even or odd, depending on TBD); if no unused streams 242 are available a negotiation to increase the number is done. It 243 should also check that the other side has the same channel available, 244 and if not then initiate an increase in the number of streams. It 245 then sends a DATA_CHANNEL_OPEN control message on the outgoing 246 stream. 248 When an DATA_CHANNEL_OPEN is received on an incoming stream, the 249 Stream is associated with the newly-created Channel. If any data had 250 arrived on the Stream before the Open arrives and had been buffered, 251 it is now released on the new Channel. 253 The channel_type and reliability_parameters fields of the 254 DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of 255 the Channel so that both directions use the same options by default. 257 7.2. Closing a Channel 259 Channels MUSTl be closed by resetting the outgoing stream If an 260 incoming stream is reset by the peer, an corresponding outgoing 261 stream reset SHOULD be issued. If both streams of a channel are 262 reset, the channel is closed and the streams are available for reuse 263 for new channel opens. 265 7.3. Sending and Receiving Data 267 Data shall be sent using PPID's other than the Data Channel Control 268 PPID. These PPID's should be registered with IANA via (TBD). The 269 meaning of these data PPIDs and the format of the data shall be 270 specific to the usage of this protocol, and typically shall be 271 provided to the higher layers to allow proper decoding of the data. 273 It is RECOMMENDED that higher layers wishing to transfer large 274 messages fragment them using PPIDs or other mechanisms to avoid 275 monopolization of the SCTP association by the transfer of a single 276 large message, unless a future SCTP draft relaxes this concern. If 277 fragmented solely with PPID values, then transmission must occur on a 278 reliable in-order channel. If in-band application framing is used, 279 then other options may be possible. 281 For WebRTC, data PPID's for DOMStrings and binary data (and 282 fragmentation thereof) shall be created. 284 All data sent on a Channel in both directions MUST be sent over the 285 underlying Stream using the reliability defined when the Channel was 286 opened unless the options are changed, or per-message options are 287 specified by a higher level. 289 Data may be sent immediately after sending or receiving a 290 DATA_CHANNEL_OPEN message. 292 It is recommended that message size be kept within certain size 293 bounds (TBD) as applications wil not be able to support arbitrarily- 294 large single messages. 296 8. Security Considerations 298 To be done. 300 9. IANA Considerations 302 This document also defines three new SCTP Payload Protocol 303 Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from 304 which these identifiers have been assigned. The following values 305 have been reserved: 307 WebRTC Control - #To Be Assigned 308 NOTE: not needed if Stream 0 is dedicated to control 309 DOMString - #To Be Assigned 310 Binary Data Partial - #To Be Assigned 311 Binary Data Last - #To Be Assigned 313 10. Acknowledgments 315 The authors wish to thank Martin Thompson, Cullen Jennings, Harald 316 Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall 317 Stewart, Stefan Haekansson and many others for their invaluable 318 comments. 320 11. References 322 11.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 328 Conrad, "Stream Control Transmission Protocol (SCTP) 329 Partial Reliability Extension", RFC 3758, May 2004. 331 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 332 RFC 4960, September 2007. 334 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 335 Security Version 1.2", RFC 6347, January 2012. 337 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 338 Transmission Protocol (SCTP) Stream Reconfiguration", 339 RFC 6525, February 2012. 341 [I-D.ietf-mmusic-sctp-sdp] 342 Loreto, S. and G. Camarillo, "Stream Control Transmission 343 Protocol (SCTP)-Based Media Transport in the Session 344 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-03 345 (work in progress), January 2013. 347 [I-D.tuexen-tsvwg-sctp-dtls-encaps] 348 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 349 Encapsulation of SCTP Packets for RTCWEB", 350 draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress), 351 July 2012. 353 11.2. Informational References 355 [I-D.ietf-rtcweb-overview] 356 Alvestrand, H., "Overview: Real Time Protocols for Brower- 357 based Applications", draft-ietf-rtcweb-overview-06 (work 358 in progress), February 2013. 360 [I-D.ietf-rtcweb-data-channel] 361 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 362 Channels", draft-ietf-rtcweb-data-channel-03 (work in 363 progress), February 2013. 365 Authors' Addresses 367 Randell Jesup 368 Mozilla 369 US 371 Email: randell-ietf@jesup.org 373 Salvatore Loreto 374 Ericsson 375 Hirsalantie 11 376 Jorvas 02420 377 FI 379 Email: salvatore.loreto@ericsson.com 381 Michael Tuexen 382 Muenster University of Applied Sciences 383 Stegerwaldstrasse 39 384 Steinfurt 48565 385 DE 387 Email: tuexen@fh-muenster.de