One document matched: draft-jesup-rtcweb-data-protocol-04.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902"
docName="draft-jesup-rtcweb-data-protocol-04.txt" category='std'>
<front>
<title>WebRTC Data Channel Protocol</title>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country>US</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>FI</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>DE</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>RTCWeb Working Group</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The DataChannel Protocol is designed to provide, in the WebRTC context
<xref target='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 <xref target='I-D.ietf-rtcweb-data-channel'/> the protocol
uses Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/>
encapsulated on Datagram Transport Layer Security (DTLS) <xref target="RFC6347"/>
as described in <xref target='I-D.tuexen-tsvwg-sctp-dtls-encaps'/> to benefit
from their already standardized transport and security features.</t>
</section>
<section anchor='con' title="Conventions">
<t>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 <xref target='RFC2119'/>.</t>
</section>
<section title='Terminology'>
<t>This document uses the following terms:
<list style='hanging'>
<t hangText='Association:'>
An SCTP association.</t>
<t hangText='Stream:'>
A unidirectional stream of an SCTP association. It is uniquely identified
by a stream identifier.</t>
<t hangText='Channel:'>
Two Streams with the same identifier, one in each direction, that are managed together.</t>
</list></t>
</section>
<section title="Protocol Overview">
<t>This protocol is a simple, low-overhead way to establish bidirectional
Channels over an SCTP association with a consistent set of properties.</t>
<t>Channels are created by sending an DATA_CHANNEL_OPEN message on an
unused Stream. There is no handshake, and the channel is available to send
on as soon as the DATA_CHANNEL_OPEN has been sent.</t>
<t>To avoid glare in opening Channels, each side must use either even or
odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to
determine which side uses odd or even is TBD and may be based on DTLS
connection roles when used in rtcweb.</t>
<t>There is no attempt to resolve label glare; if both sides open a Channel
labelled "x" at the same time, there will be two Channels labelled "x" -
one on an even Stream pair, one on an odd pair.</t>
<t>The protocol field is to ease cross-application interoperation
("federation") by identifying the data being passed with an IANA-registered
string.</t>
<t>Data that arrives which on an unused Stream MUST be held <!-- FIXME: for
how long? --> until a DATA_CHANNEL_OPEN arrived for that Channel, or if the
protocol stack had been told to expect data on that Stream and deliver it
immediately, or until [TBD - report error]. This allows for external
negotiation of streams (or assumption of negotiation by cooperating
applications). If a later DATA_CHANNEL_OPEN arrives that conflicts with
the pre-set properties of the Channel, an error should be signaled to
higher levels.</t>
<t>Channels are closed by resetting the Stream.</t>
</section>
<section title="Opening Handshake">
<t>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.</t>
<t><xref target='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).</t>
<t>The SCTP association is created with the number of streams specified by
the application, and if not specified, then it SHOULD default to 16
streams.</t>
<t>It is recommended that additional streams be available dynamically based
on <xref target="RFC6525"/>.</t>
</section>
<section title="Control Messages">
<t>Control Messages are sent to manage opening bidirectional channels.</t>
<t>A DATA_CHANNEL_OPEN message is sent on the Stream that is intended to be
used to send in that direction, and this creates a bidirectional Channel
that may be used by both sides to send data.</t>
<section title="DATA_CHANNEL_OPEN Message">
<t>This message is sent initially on the stream used for user messages
using the channel. All DATA_CHANNEL_OPEN messages MUST be sent reliably
and in-order.</t>
<t>
<figure align='center'>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Channel Type | Reliability Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority r | Label Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Length | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
\ |
| Label |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
| Protocol |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t><list style='hanging'>
<t hangText="Message Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This field holds the IANA defined message type for the the DATA_CHANNEL_OPEN
message. The suggested value of this field for IANA is 0x03. NOTE: values
0x00-0x02 were used in an older draft with incompatible structures. Any
future incompatible message changes should define new message types.</t>
<t hangText="Channel Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This field specifies the type of the channel to be opened:
<list style='hanging'>
<t hangText='DATA_CHANNEL_RELIABLE (0x00):'>
The channel provides a reliable in-order bi-directional communication
channel.</t>
<t hangText='DATA_CHANNEL_RELIABLE_UNORDERED (0x80):'>
The channel provides a reliable unordered bi-directional communication
channel.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):'>
The channel provides a partially-reliable in-order bi-directional
Communication channel. User messages will not be retransmitted more times
than specified in the Reliability Parameter.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81):'>
The channel provides a partial reliable unordered bi-directional
Communication channel. User messages will not be retransmitted more times
than specified in the Reliability Parameter.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):'>
The channel provides a partial reliable in-order 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 Javascript engine.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (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 Javascript engine.</t>
</list>
</t>
<t hangText="Reliability Parameter: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
This field is ignored if a reliable channel is used.
<vspace blankLines="0"/>
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.</t>
<t hangText="Priority: 2 bytes (integer)">
<vspace blankLines="0"/>
The priority of the channel.</t>
<t hangText="Label Length: 2 bytes (integer)">
<vspace blankLines="0"/>
The length of the label field in bytes.</t>
<t hangText="Protocol Length: 2 bytes (integer)">
<vspace blankLines="0"/>
The length of the protocol field in bytes.</t>
<t hangText="Label: Variable Length (sequence of characters)">
<vspace blankLines="0"/>
The name of the channel. This may be an empty string.</t>
<t hangText="Protocol: Variable Length (sequence of characters)">
<vspace blankLines="0"/>
The protocol for the channel. This may be an empty string. If used, it
SHOULD be an IANA-registered protocol.</t>
</list>
</t>
</section>
</section>
<section title='Procedures'>
<section title="Adding a Channel">
<t>When one side wants to add a channel, it picks an unused outgoing stream
(either even or odd, depending on TBD); if no unused streams are available
a negotiation to increase the number is done. It should also check that
the other side has the same channel available, and if not then initiate an
increase in the number of streams. It then sends a DATA_CHANNEL_OPEN
control message on the outgoing stream.</t>
<t>When an DATA_CHANNEL_OPEN is received on an incoming stream, the Stream
is associated with the newly-created Channel. If any data had arrived on
the Stream before the Open arrives and had been buffered, it is now
released on the new Channel.</t>
<t>The channel_type and reliability_parameters fields of the
DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of the
Channel so that both directions use the same options by default.</t>
</section>
<section title="Closing a Channel">
<t>Channels MUSTl be closed by resetting the outgoing stream
If an incoming stream is reset by the peer, an corresponding outgoing
stream reset SHOULD be issued. If both streams of a channel are reset,
the channel is closed and the streams are available for reuse for new channel opens.</t>
</section>
<section title="Sending and Receiving Data">
<t>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.</t>
<t>It is RECOMMENDED that higher layers wishing to transfer large messages
fragment them using PPIDs or other mechanisms to avoid monopolization of
the SCTP association by the transfer of a single large message, unless a
future SCTP draft relaxes this concern. If fragmented solely with PPID
values, then transmission must occur on a reliable in-order channel. If
in-band application framing is used, then other options may be possible.</t>
<t>For WebRTC, data PPID's for DOMStrings and binary data (and
fragmentation thereof) shall be created.</t>
<t>All data sent on a Channel in both directions MUST be sent over the
underlying Stream using the reliability defined when the Channel was
opened unless the options are changed, or per-message options are specified
by a higher level.</t>
<t>Data may be sent immediately after sending or receiving a
DATA_CHANNEL_OPEN message.</t>
<t>It is recommended that message size be kept within certain size bounds
(TBD) as applications wil not be able to support arbitrarily-large single
messages.</t>
</section>
</section>
<section title="Security Considerations" anchor="sec-security">
<t>
To be done.
</t>
</section>
<section title="IANA Considerations" anchor="sec-IANA">
<t>This document also defines three new SCTP Payload Protocol Identifiers
(PPIDs). RFC 4960 <xref target="RFC4960"/> creates the registry from which these
identifiers have been assigned. The following values have been
reserved:
<vspace blankLines="1"/>
<list style='hanging'>
<t hangText='WebRTC Control -'> #To Be Assigned</t>
<t>NOTE: not needed if Stream 0 is dedicated to control</t>
<t hangText='DOMString -'> #To Be Assigned</t>
<t hangText='Binary Data Partial -'> #To Be Assigned</t>
<t hangText='Binary Data Last -'> #To Be Assigned</t>
</list></t>
</section>
<section title="Acknowledgments">
<t>The authors wish to thank Martin Thompson, Cullen Jennings, Harald
Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall Stewart,
Stefan Håkansson and many others for their invaluable comments.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3758"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.6525"?>
<?rfc include="reference.I-D.ietf-mmusic-sctp-sdp"?>
<?rfc include="reference.I-D.tuexen-tsvwg-sctp-dtls-encaps"?>
</references>
<references title="Informational References">
<?rfc include='reference.I-D.ietf-rtcweb-overview' ?>
<?rfc include='reference.I-D.ietf-rtcweb-data-channel' ?>
</references>
</back>
</rfc>
<!-- Change log
-02 Major changes from 3-way handshake to 1-way declarative open
-->
| PAFTECH AB 2003-2026 | 2026-04-23 20:34:01 |