RTCWeb Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto Expires: September 7, 2012 Ericsson M. Tuexen Muenster University of Applied Sciences March 6, 2012 WebRTC Data Channel Protocol draft-jesup-rtcweb-data-protocol-00.txt Abstract The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies an actual (minor) protocol for how the JS-layer dataChannel objects provide the data channels between the peers. This minor protocol has applicability to other bidirectional uses of SCTP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 7, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Jesup, et al. Expires September 7, 2012 [Page 1] Internet-Draft data protocol P2P in RTCWEB March 2012 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Opening handshake . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Control Messages . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Adding a Channel . . . . . . . . . . . . . . . . . . . . . 6 4.2. Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 5. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informational References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Jesup, et al. Expires September 7, 2012 [Page 2] Internet-Draft data protocol P2P in RTCWEB March 2012 1. Introduction The Data Channel Protocol is designed to provide, in the WebRTC context [I-D.ietf-rtcweb-overview], a generic transport service allowing Web Browser to exchange generic data in a bidirectional peer to peer fashion. As discussed in [I-D.jesup-rtcweb-data] the protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] to benefit from their transport and security already standardized features. 2. Opening handshake The opening handshake is based on the multimedia session description exchange that happens between the browsers, typically through a Web Server acting as the signaling service. The draft [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier, 'SCTP/DTLS', and defines how to establish an SCTP association over DTLS using the Session Description Protocol (SDP). The SCTP association is created with the number of streams specified by the application, and if not specified, then it shall default to 16 streams. It is recommended that additional streams be available dynamically based on [RFC6525]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3.1. Terminology This document uses the following terms: Association: An SCTP association. Stream: A unidirectional stream of an SCTP association. It is uniquely identified by a stream identifier. 4. Control Messages Data Channel Control Messages are sent to manage opening Jesup, et al. Expires September 7, 2012 [Page 3] Internet-Draft data protocol P2P in RTCWEB March 2012 bidirectional channels. A DATA_CHANNEL_OPEN is sent on the Stream that is intended to be used to send in that direction, and a response (DATA_CHANNEL_OPEN_RESPONSE) using the same structure is sent back on the Stream to be used for the other direction, with a reverse_direction_stream entry holding the Stream number the DATA_CHANNEL_OPEN was sent on. This allows association of the Streams that define the bidirectional channel. Errors are returned by setting the first 16 bits of the msg_type_data field to a non-0 value. In this case the original sender of DATA_CHANNEL_OPEN shall close the channel. Jesup, et al. Expires September 7, 2012 [Page 4] Internet-Draft data protocol P2P in RTCWEB March 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPID = Data Channel Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg_type | channel_type | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reverse_direction_stream | reliability_parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg_type_data \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'msg_type' contains: DATA_CHANNEL_OPEN 0 DATA_CHANNEL_OPEN_RESPONSE 1 'channel_type' contains: DATA_CHANNEL_RELIABLE 0 DATA_CHANNEL_RELIABLE_STREAM 1 DATA_CHANNEL_UNRELIABLE 2 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 3 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 4 'flags' contains: DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED 0x0001 all other bits are reserved 'msg_type_data' contains: for DATA_CHANNEL_OPEN: a DOMString label for the data channel for DATA_CHANNEL_OPEN_RESPONSE: a 16-bit value for errors or 0 for no error 'reliability_parameters' contains (as unsigned 16-bit numbers): for DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT: the maximum number of retransmits or 0 for none for DATA_CHANNEL_PARTIAL_RELIABLE_TIMED: the maximum time in ms to attempt to deliver the data or 0 for no attempts. Jesup, et al. Expires September 7, 2012 [Page 5] Internet-Draft data protocol P2P in RTCWEB March 2012 Figure 1: Data Channel control messages: OPEN and OPEN_RESPONSE Messages Note that the forward and reverse-direction Stream numbers may be different if both sides attempt to open the same Stream number at the same time, and the protocol does not require they be the same. Control messages shall be sent on the relevant Streams, and shall be sent using reliable, in-order delivery. 4.1. Adding a Channel When one side wants to add a channel, it picks an unused Stream, and if need be, negotiates an increase in the number of Streams available. It then sends a DATA_CHANNEL_OPEN control message on the Stream, with reverse_direction_stream set to 0, though that value MUST be ignored by the recipient. When a DATA_CHANNEL_OPEN is received on a Stream, an unused Stream is picked, and if need be, negotiates an increase in the number of Streams available. A DATA_CHANNEL_OPEN_RESPONSE is sent on the Stream, with reverse_direction_stream set to the Stream the DATA_CHANNEL_OPEN request came in on. When a DATA_CHANNEL_OPEN_RESPONSE is received, the reverse_direction_stream value is matched against all pending DATA_CHANNEL_OPENs. If no match can be found, the DATA_CHANNEL_OPEN_RESPONSE should be ignored. If a match is found, then if the error value is 0 the bidirectional Data Channel is now established and ready for use. If the error value is non-zero, the open failed, and the originator should close down the originally- selected Stream and notify the application. An alternative to embedding the control messages on the Streams used for data transfer would be to put them on a reserved Stream (0 for example), and add an additional field for the forward_direction_stream. The channel_type and reliability_parameters fields of the DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of the Data Channel so that both directions use the same options. 4.2. Closing a Channel Data Channels shall be closed by doing an SCTP Stream Sequence Number reset, which should guarantee that all data sent before closing is delivered or has been abandoned (for partially-reliable Data Channels). Jesup, et al. Expires September 7, 2012 [Page 6] Internet-Draft data protocol P2P in RTCWEB March 2012 5. Sending and Receiving Data Data shall be sent using PPID's other than the Data Channel Control PPID. These PPID's should be registered with IANA via (TBD). The meaning of these data PPIDs and the format of the data shall be specific to the usage of this protocol, and typically shall be provided to the higher layers to allow proper decoding of the data. For WebRTC, data PPID's for DOMStrings and binary data blobs shall be created. All data sent on a Data Channel in both directions MUST be sent over the underlying Stream using the reliability defined when the Data Channel was opened. It is recommended that message size be kept within certain bounds (TBD). 6. Security Considerations To be done. 7. IANA Considerations This document also defines three new SCTP Payload Protocol Identifiers (PPIDs). RFC 4960 [RFC4960] creates the registry from which these identifiers have been assigned. The following values have been reserved: WebRTC Control - #To Be Assigned DOMString - #To Be Assigned Binary Data - #To Be Assigned 8. Acknowledgments Many thanks for comments, ideas, and text ... (TBD) 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Jesup, et al. Expires September 7, 2012 [Page 7] Internet-Draft data protocol P2P in RTCWEB March 2012 [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-00 (work in progress), July 2011. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. 9.2. Informational References [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- based Applications", draft-ietf-rtcweb-overview-02 (work in progress), September 2011. [I-D.jesup-rtcweb-data] Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram Connection", draft-jesup-rtcweb-data-01 (work in progress), October 2011. Authors' Addresses Randell Jesup Mozilla USA Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Jesup, et al. Expires September 7, 2012 [Page 8] Internet-Draft data protocol P2P in RTCWEB March 2012 Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 Germany Email: tuexen@fh-muenster.de Jesup, et al. Expires September 7, 2012 [Page 9]