--- 1/draft-ietf-rtcweb-data-protocol-05.txt 2014-06-09 23:14:26.467607447 -0700 +++ 2/draft-ietf-rtcweb-data-protocol-06.txt 2014-06-09 23:14:26.495608154 -0700 @@ -1,21 +1,21 @@ Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: November 16, 2014 Ericsson +Expires: December 11, 2014 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - May 15, 2014 + June 9, 2014 WebRTC Data Channel Establishment Protocol - draft-ietf-rtcweb-data-protocol-05.txt + draft-ietf-rtcweb-data-protocol-06.txt Abstract The Real-Time Communication in WEB-browsers working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. @@ -27,21 +27,21 @@ 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 November 16, 2014. + This Internet-Draft will expire on December 11, 2014. Copyright Notice Copyright (c) 2014 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 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 @@ -62,21 +62,21 @@ 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 10.2. Informational References . . . . . . . . . . . . . . . . 11 + 10.2. Informational References . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Data Channel Establishment Protocol (DCEP) is designed to provide, in the WebRTC data channel context [I-D.ietf-rtcweb-data-channel], a simple in-band method to open symmetric data channels. As discussed in [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram @@ -100,58 +100,59 @@ uniquely identified by an SCTP stream identifier (0-65534). Note: the SCTP stream identifier 65535 is reserved due to SCTP INIT and INIT-ACK chunks only allowing a maximum of 65535 streams to be negotiated (0-65534). Channel: Two Streams with the same SCTP stream identifier, one in each direction, which are managed together. 4. Protocol Overview - This protocol is a simple, low-overhead way to establish - bidirectional Channels over an SCTP association with a consistent set - of properties. + The Data Channel Establishment Protocol is a simple, low-overhead way + to establish bidirectional Channels over an SCTP association with a + consistent set of properties. The set of consistent properties includes: - o whether the messages are transmitted reliable or unreliable. In - case of unreliable transmissions, the same level of unreliability - is used. + o reliable or unreliable message transmission. In case of + unreliable transmissions, the same level of unreliability is used. - o whether the messages are delivered in-order or out-of order. + o in-order or out-of-order message delivery. o the priority of the Channel. o an optional label for the Channel. o an optional protocol for the Channel. o the SCTP streams. - The Data Channel Establishment Protocol uses a two way handshake to - open a data channel by combining two SCTP streams, one in each - direction, with the same SCTP stream identifier. The side wanting to - open a data channel selects an SCTP stream identifier for which the - corresponding incoming and outgoing SCTP streams are unused and sends - a DATA_CHANNEL_OPEN message on the outgoing SCTP stream. The peer - responds with a DATA_CHANNEL_ACK message on its corresponding - outgoing SCTP stream. Then the data channel is open. Please note - that the opening side can send user messages before the - DATA_CHANNEL_ACK is received. Data channel messages are sent on the - same Stream as the user messages belonging to the data channel. The + This protocol uses a two way handshake to open a data channel. The + handshake pairs one incoming and one outgoing SCTP stream, both + having the same SCTP stream identifier, into a single bidirectional + channel. The side wanting to open a data channel selects an SCTP + stream identifier for which the corresponding incoming and outgoing + SCTP streams are unused and sends a DATA_CHANNEL_OPEN message on the + outgoing SCTP stream. The peer responds with a DATA_CHANNEL_ACK + message on its corresponding outgoing SCTP stream. Then the data + channel is open. Data channel messages are sent on the same Stream + as the user messages belonging to the data channel. The demultiplexing is based on the SCTP payload protocol identifier (PPID), since the Data Channel Establishment Protocol uses a specific PPID. + Note: The opening side can send user messages before the + DATA_CHANNEL_ACK is received. + To avoid glare in opening Channels, each side MUST use Streams with either even or odd SCTP stream identifiers when sending a - DATA_CHANNEL_OPEN message. When using + DATA_CHANNEL_OPEN message. When using SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which side uses odd or even is based on the underlying DTLS connection role: the side acting as the DTLS client MUST use Streams with even SCTP stream identifiers, the side acting as the DTLS server MUST use Streams with odd SCTP stream identifiers. Note: There is no attempt to resolve label glare; if both sides open a Channel labeled "x" at the same time, there will be two Channels labeled "x" - one on an even Stream pair, one on an odd pair. @@ -226,22 +227,21 @@ DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel provides a partial reliable unordered bi-directional communication channel. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the protocol stack. Priority: 2 bytes (unsigned integer) The priority of the channel as described in - [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower - the priority. + [I-D.ietf-rtcweb-data-channel]. Reliability Parameter: 4 bytes (unsigned integer) For reliable channels this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side. If a partial reliable channel with limited number of retransmissions is used, this field specifies the number of retransmissions. If a partial reliable channel with limited lifetime is used, this field specifies the maximum lifetime in milliseconds. The following table summarizes this: @@ -458,23 +458,24 @@ | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] | | Unassigned | rest | | +------------------------------------------------+------+-----------+ 9. Acknowledgments The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry - Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Irene - Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, Justin - Uberti, and many others for their invaluable comments. + Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Doug + Leonard, Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin + Thompson, Justin Uberti, and many others for their invaluable + comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. @@ -491,22 +492,22 @@ Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-04 (work in progress), May 2014. 10.2. Informational References [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data - Channels", draft-ietf-rtcweb-data-channel-08 (work in - progress), April 2014. + Channels", draft-ietf-rtcweb-data-channel-09 (work in + progress), May 2014. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-06 (work in progress), January 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-09 (work in progress), February 2014. Authors' Addresses