idnits 2.17.1 draft-jesup-rtcweb-data-protocol-00.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 (March 6, 2012) is 4431 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) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-00 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-02 Summary: 2 errors (**), 0 flaws (~~), 3 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: September 7, 2012 Ericsson 6 M. Tuexen 7 Muenster University of Applied 8 Sciences 9 March 6, 2012 11 WebRTC Data Channel Protocol 12 draft-jesup-rtcweb-data-protocol-00.txt 14 Abstract 16 The Web Real-Time Communication (WebRTC) working group is charged to 17 provide protocols to support for direct interactive rich 18 communication using audio, video, and data between two peers' web- 19 browsers. This document specifies an actual (minor) protocol for how 20 the JS-layer dataChannel objects provide the data channels between 21 the peers. 23 This minor protocol has applicability to other bidirectional uses of 24 SCTP. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 7, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Opening handshake . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.1. Adding a Channel . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 67 5. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 73 9.2. Informational References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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.jesup-rtcweb-data] the 82 protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960] 83 encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] to 84 benefit from their transport and security already standardized 85 features. 87 2. Opening handshake 89 The opening handshake is based on the multimedia session description 90 exchange that happens between the browsers, typically through a Web 91 Server acting as the signaling service. 93 The draft [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 94 'SCTP/DTLS', and defines how to establish an SCTP association over 95 DTLS using the Session Description Protocol (SDP). 97 The SCTP association is created with the number of streams specified 98 by the application, and if not specified, then it shall default to 16 99 streams. 101 It is recommended that additional streams be available dynamically 102 based on [RFC6525]. 104 3. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3.1. Terminology 112 This document uses the following terms: 114 Association: An SCTP association. 115 Stream: A unidirectional stream of an SCTP association. It is 116 uniquely identified by a stream identifier. 118 4. Control Messages 120 Data Channel Control Messages are sent to manage opening 121 bidirectional channels. A DATA_CHANNEL_OPEN is sent on the Stream 122 that is intended to be used to send in that direction, and a response 123 (DATA_CHANNEL_OPEN_RESPONSE) using the same structure is sent back on 124 the Stream to be used for the other direction, with a 125 reverse_direction_stream entry holding the Stream number the 126 DATA_CHANNEL_OPEN was sent on. This allows association of the 127 Streams that define the bidirectional channel. 129 Errors are returned by setting the first 16 bits of the msg_type_data 130 field to a non-0 value. In this case the original sender of 131 DATA_CHANNEL_OPEN shall close the channel. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Type = 0 | Reserved|U|B|E| Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | TSN | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Stream Identifier S | Stream Sequence Number n | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | PPID = Data Channel Control | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | msg_type | channel_type | flags | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | reverse_direction_stream | reliability_parameters | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | msg_type_data \ 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 \ \ 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 'msg_type' contains: 154 DATA_CHANNEL_OPEN 0 155 DATA_CHANNEL_OPEN_RESPONSE 1 157 'channel_type' contains: 158 DATA_CHANNEL_RELIABLE 0 159 DATA_CHANNEL_RELIABLE_STREAM 1 160 DATA_CHANNEL_UNRELIABLE 2 161 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 3 162 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 4 164 'flags' contains: 165 DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED 0x0001 166 all other bits are reserved 168 'msg_type_data' contains: 169 for DATA_CHANNEL_OPEN: 170 a DOMString label for the data channel 171 for DATA_CHANNEL_OPEN_RESPONSE: 172 a 16-bit value for errors or 0 for no error 174 'reliability_parameters' contains (as unsigned 16-bit numbers): 175 for DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT: 176 the maximum number of retransmits or 0 for none 177 for DATA_CHANNEL_PARTIAL_RELIABLE_TIMED: 178 the maximum time in ms to attempt to deliver the data 179 or 0 for no attempts. 181 Figure 1: Data Channel control messages: OPEN and OPEN_RESPONSE 182 Messages 184 Note that the forward and reverse-direction Stream numbers may be 185 different if both sides attempt to open the same Stream number at the 186 same time, and the protocol does not require they be the same. 188 Control messages shall be sent on the relevant Streams, and shall be 189 sent using reliable, in-order delivery. 191 4.1. Adding a Channel 193 When one side wants to add a channel, it picks an unused Stream, and 194 if need be, negotiates an increase in the number of Streams 195 available. It then sends a DATA_CHANNEL_OPEN control message on the 196 Stream, with reverse_direction_stream set to 0, though that value 197 MUST be ignored by the recipient. 199 When a DATA_CHANNEL_OPEN is received on a Stream, an unused Stream is 200 picked, and if need be, negotiates an increase in the number of 201 Streams available. A DATA_CHANNEL_OPEN_RESPONSE is sent on the 202 Stream, with reverse_direction_stream set to the Stream the 203 DATA_CHANNEL_OPEN request came in on. 205 When a DATA_CHANNEL_OPEN_RESPONSE is received, the 206 reverse_direction_stream value is matched against all pending 207 DATA_CHANNEL_OPENs. If no match can be found, the 208 DATA_CHANNEL_OPEN_RESPONSE should be ignored. If a match is found, 209 then if the error value is 0 the bidirectional Data Channel is now 210 established and ready for use. If the error value is non-zero, the 211 open failed, and the originator should close down the originally- 212 selected Stream and notify the application. 214 An alternative to embedding the control messages on the Streams used 215 for data transfer would be to put them on a reserved Stream (0 for 216 example), and add an additional field for the 217 forward_direction_stream. 219 The channel_type and reliability_parameters fields of the 220 DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of 221 the Data Channel so that both directions use the same options. 223 4.2. Closing a Channel 225 Data Channels shall be closed by doing an SCTP Stream Sequence Number 226 reset, which should guarantee that all data sent before closing is 227 delivered or has been abandoned (for partially-reliable Data 228 Channels). 230 5. Sending and Receiving Data 232 Data shall be sent using PPID's other than the Data Channel Control 233 PPID. These PPID's should be registered with IANA via (TBD). The 234 meaning of these data PPIDs and the format of the data shall be 235 specific to the usage of this protocol, and typically shall be 236 provided to the higher layers to allow proper decoding of the data. 238 For WebRTC, data PPID's for DOMStrings and binary data blobs shall be 239 created. 241 All data sent on a Data Channel in both directions MUST be sent over 242 the underlying Stream using the reliability defined when the Data 243 Channel was opened. 245 It is recommended that message size be kept within certain bounds 246 (TBD). 248 6. Security Considerations 250 To be done. 252 7. IANA Considerations 254 This document also defines three new SCTP Payload Protocol 255 Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from 256 which these identifiers have been assigned. The following values 257 have been reserved: 259 WebRTC Control - #To Be Assigned 260 DOMString - #To Be Assigned 261 Binary Data - #To Be Assigned 263 8. Acknowledgments 265 Many thanks for comments, ideas, and text ... (TBD) 267 9. References 269 9.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 [I-D.ietf-mmusic-sctp-sdp] 275 Loreto, S. and G. Camarillo, "Stream Control Transmission 276 Protocol (SCTP)-Based Media Transport in the Session 277 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-00 278 (work in progress), July 2011. 280 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 281 RFC 4960, September 2007. 283 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 284 Security Version 1.2", RFC 6347, January 2012. 286 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 287 Transmission Protocol (SCTP) Stream Reconfiguration", 288 RFC 6525, February 2012. 290 9.2. Informational References 292 [I-D.ietf-rtcweb-overview] 293 Alvestrand, H., "Overview: Real Time Protocols for Brower- 294 based Applications", draft-ietf-rtcweb-overview-02 (work 295 in progress), September 2011. 297 [I-D.jesup-rtcweb-data] 298 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram 299 Connection", draft-jesup-rtcweb-data-01 (work in 300 progress), October 2011. 302 Authors' Addresses 304 Randell Jesup 305 Mozilla 306 USA 308 Email: randell-ietf@jesup.org 310 Salvatore Loreto 311 Ericsson 312 Hirsalantie 11 313 Jorvas 02420 314 Finland 316 Email: salvatore.loreto@ericsson.com 317 Michael Tuexen 318 Muenster University of Applied Sciences 319 Stegerwaldstrasse 39 320 Steinfurt 48565 321 Germany 323 Email: tuexen@fh-muenster.de