One document matched: draft-ietf-rtcweb-data-protocol-06.xml
<?xml version='1.0'?>
<?rfc symrefs='yes'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc sortrefs='no' ?>
<?rfc strict='yes' ?>
<rfc category='std'
ipr='trust200902'
docName='draft-ietf-rtcweb-data-protocol-06.txt'>
<front>
<title>WebRTC Data Channel Establishment 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>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>The Data Channel Establishment Protocol (DCEP) is designed to provide, in the
WebRTC data channel context <xref target='I-D.ietf-rtcweb-data-channel'/>,
a simple in-band method to open symmetric data channels.
As discussed in <xref target='I-D.ietf-rtcweb-data-channel'/>, the protocol uses
the Stream Control Transmission Protocol (SCTP) <xref target='RFC4960'/>
encapsulated in the Datagram Transport Layer Security (DTLS)
<xref target='RFC6347'/> as described in
<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/> to benefit
from their already standardized transport and security features.</t>
</section>
<section 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 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).</t>
<t hangText='Channel:'>
Two Streams with the same SCTP stream identifier, one in each direction,
which are managed together.</t>
</list></t>
</section>
<section title='Protocol Overview'>
<t>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.</t>
<t>The set of consistent properties includes:
<list style='symbols'>
<t>reliable or unreliable message transmission. In case of unreliable
transmissions, the same level of unreliability is used.</t>
<t>in-order or out-of-order message delivery.</t>
<t>the priority of the Channel.</t>
<t>an optional label for the Channel.</t>
<t>an optional protocol for the Channel.</t>
<t>the SCTP streams.</t>
</list></t>
<t>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.</t>
<t>Note: The opening side can send user messages before the DATA_CHANNEL_ACK
is received.</t>
<t>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 SCTP over DTLS <xref target='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.</t>
<t>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.</t>
<t>The protocol field is to ease cross-application interoperation ("federation")
by identifying the user data being passed with an IANA-registered string
('WebSocket Subprotocol Name Registry' defined in <xref target='RFC6455'/>),
and may be useful for homogeneous applications which may create more than one
type of Channel.
Please note that there is also no attempt to resolve protocol glare.</t>
</section>
<section title='Message Formats'
anchor='msg_format'>
<t>Every Data Channel Establishment Protocol message starts with a one byte
field called "Message Type" which indicates the type of the message.
The corresponding values are managed by IANA
(see <xref target='iana_msg_type'/>).</t>
<section title='DATA_CHANNEL_OPEN Message'
anchor='open_msg_format'>
<t>This message is sent initially on the stream used for user messages
using the channel.</t>
<figure>
<artwork align='center'>
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 | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Length | Protocol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
| Label |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
| Protocol |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<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 DATA_CHANNEL_OPEN
message. The suggested value of this field for IANA is 0x03.</t>
<t hangText='Channel Type: 1 byte (unsigned integer)'>
<vspace blankLines='0'/>
This field specifies the type of the channel to be opened and the
values are managed by IANA (see <xref target='iana_channel_type'/>):
<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 protocol stack.</t>
<t hangText='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.</t>
</list></t>
<t hangText='Priority: 2 bytes (unsigned integer)'>
<vspace blankLines='0'/>
The priority of the channel as described in
<xref target='I-D.ietf-rtcweb-data-channel'/>.</t>
<t hangText='Reliability Parameter: 4 bytes (unsigned integer)'>
<vspace blankLines='0'/>
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:</t>
</list></t>
<texttable>
<ttcol align='left'>Channel Type</ttcol>
<ttcol align='center'>Reliability Parameter</ttcol>
<c>DATA_CHANNEL_RELIABLE</c> <c>Ignored</c>
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c> <c>Ignored</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c> <c>Number of RTX</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c><c>Number of RTX</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c> <c>Lifetime in ms</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>Lifetime in ms</c>
</texttable>
<t><list style='hanging'>
<t hangText='Label Length: 2 bytes (unsigned integer)'>
<vspace blankLines='0'/>
The length of the label field in bytes.</t>
<t hangText='Protocol Length: 2 bytes (unsigned 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 as a UTF-8 encoded string.
This may be an empty string.</t>
<t hangText='Protocol: Variable Length (sequence of characters)'>
<vspace blankLines='0'/>
The sub-protocol for the channel as a UTF-8 encoded string.
If this is an empty string the protocol is unspecified.
If it is a non-empty string, it specifies an protocol registered in the
'WebSocket Subprotocol Name Registry' created in
<xref target='RFC6455'/>.</t>
</list></t>
</section>
<section title='DATA_CHANNEL_ACK Message'>
<t>This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE
message on the stream used for user messages using the channel.
Reception of this message tells the opener that the channel setup
handshake is complete.</t>
<figure>
<artwork align='center'>
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 |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<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 DATA_CHANNEL_ACK
message. The suggested value of this field for IANA is 0x02.</t>
</list>
</t>
</section>
</section>
<section title='Procedures'>
<t>All Data Channel Establishment Protocol messages MUST be sent using
ordered delivery and reliable transmission.
They MUST be sent on the same outgoing SCTP stream as the user messages
belonging to the corresponding data channel.
Multiplexing and demultiplexing is done by using the SCTP payload protocol
identifier (PPID).
Therefore Data Channel Establishment Protocol message MUST be sent with the
assigned PPID for the Data Channel Establishment Protocol
(see <xref target='iana_ppid'/>).
Other messages MUST NOT be sent using this PPID.</t>
<t>If one side wants to open a data channel, it chooses an SCTP stream
identifier for which the corresponding incoming and outgoing SCTP streams
are free. If the side is the DTLS client, it MUST choose
an even stream identifier, if the side is the DTLS server, it MUST
choose an odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message
and sends it on the chosen SCTP stream.</t>
<t>After the DATA_CHANNEL_OPEN message has been sent, the sender of it
can start sending messages containing user data without waiting for the
reception of the corresponding DATA_CHANNEL_ACK message.
However, before the DATA_CHANNEL_ACK message or any other message has been
received on a data channel, all other messages containing user data and
belonging to this data channel MUST be sent ordered, no matter whether the
data channel is ordered or not.
After the DATA_CHANNEL_ACK or any other message has been received on the data
channel, messages containing user data MUST be send ordered on ordered data
channels and MUST be sent unordered on unordered data channels.
Therefore receiving a message containing user data on an unused SCTP stream
indicates an error. The corresponding channel MUST be closed as described in
<xref target='I-D.ietf-rtcweb-data-channel'/>.</t>
<t>If a DATA_CHANNEL_OPEN message is received on an unused stream,
the stream identifier corresponds to the role of the peer and
all parameters in the DATA_CHANNEL_OPEN message are valid,
then a corresponding DATA_CHANNEL_ACK message is sent on the stream with the
same stream identifier as the one the DATA_CHANNEL_OPEN message was received
on.</t>
<t>If a DATA_CHANNEL_OPEN message is received on an already used SCTP stream or
there are any problems with parameters within the DATA_CHANNEL_OPEN message or
the DATA_CHANNEL_OPEN message itself is not well-formed,
the receiver MUST close the corresponding channel using the procedure described
in <xref target='I-D.ietf-rtcweb-data-channel'/> and MUST NOT send a
DATA_CHANNEL_ACK message in response to the received message.
Therefore, receiving an SCTP stream reset request for a stream on which
no DATA_CHANNEL_ACK message has been received indicates to the sender of the
corresponding DATA_CHANNEL_OPEN message the failure of the data channel
setup procedure. After also successfully resetting the corresponding outgoing
SCTP stream, which concludes the channel closing initiated by the peer,
a new DATA_CHANNEL_OPEN message can be sent on the stream.</t>
</section>
<section title='Security Considerations'
anchor='sec-security'>
<t>The DATA_CHANNEL_OPEN messages contains two variable length fields:
the protocol and the label. A receiver must be prepared to receive
DATA_CHANNEL_OPEN messages where these field have the maximum length of
65535 bytes. Error cases like the use of inconsistent lengths fields,
unknown parameter values or violation the odd/even rule must also be handled
by closing the corresponding channel. An end-point must also be prepared
that the peer open the maximum number of data channels.</t>
<t>When using DCEP over SCTP encapsulated in DTLS as specified in
<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, security properties
like privacy, integrity, and source authentication can be provided by DTLS.
If DCEP is used without running over DTLS, this is not the case.</t>
<t>For general considerations see <xref target='I-D.ietf-rtcweb-security'/> and
<xref target='I-D.ietf-rtcweb-security-arch'/>.</t>
</section>
<section title='IANA Considerations'>
<t>[NOTE to RFC-Editor:
<list>
<t>"RFCXXXX" is to be replaced by the RFC number you assign this document.</t>
</list>
]</t>
<t>IANA is asked to update the reference of an already existing SCTP PPID
assignment and to create two new registries for the Data Channel
Establishment Protocol.</t>
<section title='SCTP Payload Protocol Identifier'
anchor='iana_ppid'>
<t>This document uses one already registered SCTP Payload Protocol
Identifier (PPID) named "WebRTC Control".
<xref target='RFC4960'/> creates the registry
"SCTP Payload Protocol Identifiers" from which this identifier was assigned.
IANA is requested to update the reference of this assignment to point to this
document and to update the name.
Therefore this assignment should be updated to read:</t>
<texttable>
<ttcol align='left'>Value</ttcol>
<ttcol align='left'>SCTP PPID</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>WebRTC DCEP</c> <c>50</c> <c>[RFCXXXX]</c>
</texttable>
</section>
<section title='New Message Type Registry'
anchor ='iana_msg_type'>
<t>IANA is requested to create a new registration table "Message Type Registry"
for the Data Channel Establishment Protocol (DCEP) to manage the one byte
"Message Type" field in DCEP messages (see <xref target='msg_format'/>).</t>
<t>The assignment of new message types is done through an RFC required action,
as defined in <xref target='RFC5226'/>.
Documentation of the new message type MUST contain the following information:
<list style="numbers">
<t>A name for the new message type;</t>
<t>A detailed procedural description of the use of messages with the new type
within the operation of the Data Channel Establishment Protocol.</t>
</list></t>
<t>Initially the following values need to be registered:</t>
<texttable>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Type</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>Reserved</c> <c>0x00 </c> <c>[RFCXXXX]</c>
<c>Reserved</c> <c>0x01 </c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_ACK</c> <c>0x02 </c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_OPEN</c> <c>0x03 </c> <c>[RFCXXXX]</c>
<c>Unassigned</c> <c>0x04-0xfe</c> <c> </c>
<c>Reserved</c> <c>0xff </c> <c>[RFCXXXX]</c>
</texttable>
<t>Please note that the values 0x00 and 0x01 are reserved to avoid
interoperability problems, since they have been used in earlier versions
of the document.
The value 0xff has been reserved for future extensibility.</t>
</section>
<section title='New Channel Type Registry'
anchor='iana_channel_type'>
<t>IANA is requested to create a new registration table "Channel Type Registry"
for the Data Channel Establishment Protocol to manage the one byte
"Channel Type" field in DATA_CHANNEL_OPEN messages
(see <xref target='open_msg_format'/>).</t>
<t>The assignment of new message types is done through an RFC required action,
as defined in <xref target='RFC5226'/>.
Documentation of the new channel type MUST contain the following information:
<list style="numbers">
<t>A name for the new channel type;</t>
<t>A detailed procedural description of the user message handling for
data channels using this new channel type.</t>
</list>
Please note that if new channel types support ordered and unordered message
delivery, the high order bit SHOULD be used to indicate whether the message
delivery is unordered or not.</t>
<t>Initially the following values need to be registered:</t>
<texttable>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Type</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>DATA_CHANNEL_RELIABLE</c> <c>0x00</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_RELIABLE_UNORDERED</c> <c>0x80</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT</c> <c>0x01</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED</c> <c>0x81</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED</c> <c>0x02</c> <c>[RFCXXXX]</c>
<c>DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED</c> <c>0x82</c> <c>[RFCXXXX]</c>
<c>Reserved</c> <c>0x7f</c> <c>[RFCXXXX]</c>
<c>Reserved</c> <c>0xff</c> <c>[RFCXXXX]</c>
<c>Unassigned</c> <c>rest</c> <c> </c>
</texttable>
</section>
</section>
<section title='Acknowledgments'>
<t>The authors wish to thank
Harald Alvestrand,
Adam Bergkvist,
Barry Dingle,
Stefan Håkansson,
Cullen Jennings,
Paul Kyzivat,
Doug Leonard,
Irene Ruengeler,
Randall Stewart,
Peter Thatcher,
Martin Thompson,
Justin Uberti,
and many others for their invaluable comments.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.6347'?>
<?rfc include='reference.I-D.ietf-tsvwg-sctp-dtls-encaps'?>
</references>
<references title='Informational References'>
<?rfc include='reference.RFC.6455'?>
<?rfc include='reference.I-D.ietf-rtcweb-data-channel' ?>
<?rfc include='reference.I-D.ietf-rtcweb-security'?>
<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:06 |