Abstract

The WebRTC framework specifies protocol support for direct interactiverich communication using audio, video, and data between two peers' web browsers.This document specifies a simple protocol for establishing symmetricdata channels between the peers. It uses a two-way handshake and allowssending of user data without waiting for the handshake to complete.¶

1.Introduction

The Data Channel Establishment Protocol (DCEP) is designed to provide, in theWebRTC data channel context[RFC8831],a simple in-band method for opening symmetric data channels.As discussed in[RFC8831], the protocol usesthe Stream Control Transmission Protocol (SCTP)[RFC4960]encapsulated in Datagram Transport Layer Security (DTLS) (described in[RFC8261]). This allows DCEP to benefit from thealready standardized transportand security features of SCTP and DTLS.DTLS 1.0 is defined in[RFC4347]; the presentlatest version, DTLS 1.2, is defined in[RFC6347]; and an upcoming version, DTLS 1.3, is defined in[TLS-DTLS13].¶

2.Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP?14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.Terminology

This document uses the following terms:¶

Association:

An SCTP association.¶

Stream:

A unidirectional stream of an SCTP association. It is uniquely identifiedby an SCTP stream identifier (0-65534).Note: The SCTP stream identifier 65535 is reserved due to SCTP INIT andINIT-ACK chunks only allowing a maximum of 65535 streams to benegotiated (0-65534).¶

Stream Identifier:

The SCTP stream identifier uniquely identifying a stream.¶

Data Channel:

Two streams with the same stream identifier, one in each direction,which are managed together.¶

4.Protocol Overview

The Data Channel Establishment Protocol is a simple, low-overhead wayto establish bidirectional data channels over an SCTP association with aconsistent set of properties.¶

The set of consistent properties includes:¶

• reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used.¶
• in-order or out-of-order message delivery.¶
• the priority of the data channel.¶
• an optional label for the data channel.¶
• an optional protocol for the data channel.¶
• the streams.¶

This protocol uses a two-way handshake to open a data channel.The handshake pairs one incoming and one outgoing stream, both having thesame stream identifier, into a single bidirectional data channel.The peer that initiates opening a data channel selects a streamidentifier for which the corresponding incoming and outgoing streamsare unused and sends a DATA_CHANNEL_OPEN message on the outgoing stream.The peer responds with a DATA_CHANNEL_ACK message on its correspondingoutgoing stream. Then the data channel is open.DCEP messages are sent on the same stream asthe user messages belonging to the data channel.The demultiplexing is based on the SCTP Payload Protocol Identifier (PPID),since DCEP uses a specific PPID.¶

Note: The opening sideMAY send user messages before the DATA_CHANNEL_ACKis received.¶

To avoid collisions where both sides try to open a data channel withthe same stream identifiers, each sideMUST use streams with either even orodd stream identifiers when sending a DATA_CHANNEL_OPEN message.When using SCTP over DTLS[RFC8261],the method used to determine which side uses odd or even is based on theunderlying DTLS connection role:the side acting as the DTLS clientMUST use streams with evenstream identifiers; the side acting as the DTLS serverMUST use streamswith odd stream identifiers.¶

Note: There is no attempt to ensure uniqueness for the label;if both sides open a data channel labeled "x" at the same time, there will betwo data channels labeled "x" -- one on an even stream pair, one on an odd pair.¶

The purpose of the protocol field is to ease cross-application interoperation ("federation")by identifying the user data being passed by means of an IANA-registered stringfrom the "WebSocket Subprotocol Name Registry" defined in[RFC6455].The field may be useful for homogeneous applications that may create more than onetype of data channel.Note that there is no attempt to ensure uniqueness for the protocolfield.¶

6.Procedures

All DCEP messagesMUST be sent using ordered delivery and reliabletransmission. TheyMUST be sent on the same outgoing stream as the user messagesbelonging to the corresponding data channel.Multiplexing and demultiplexing is done by using the SCTP PPID.Therefore, a DCEP messageMUST be sent with theassigned PPID for the Data Channel Establishment Protocol(seeSection 8.1).Other messagesMUST NOT be sent using this PPID.¶

The peer that initiates opening a data channel selects a stream identifierfor which the corresponding incoming and outgoing streams are unused.If the side is acting as the DTLS client, itMUST choose an even stream identifier;if the side is acting as the DTLS server, itMUST choose an odd one. The initiating peerfills in the parameters of the DATA_CHANNEL_OPEN message and sends it onthe chosen stream.¶

If a DATA_CHANNEL_OPEN message is received on an unused stream,the stream identifier corresponds to the role of the peer, andall parameters in the DATA_CHANNEL_OPEN message are valid,then a corresponding DATA_CHANNEL_ACK message is sent on the stream with thesame stream identifier as the one the DATA_CHANNEL_OPEN message wasreceived on.¶

If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, thereceiverMUST close the corresponding data channel using the proceduredescribed in[RFC8831] andMUST NOT send a DATA_CHANNEL_ACKmessage in response to the received message. This might occur if, for example,a DATA_CHANNEL_OPEN message is received on an already used stream, there areproblems with parameters within the DATA_CHANNEL_OPENmessage, the odd/even rule is violated, or the DATA_CHANNEL_OPEN message itselfis not well formed. Therefore, receiving an SCTP stream-reset request for a stream on whichno DATA_CHANNEL_ACK message has been received indicates to the sender of thecorresponding DATA_CHANNEL_OPEN message the failure of the data channelsetup procedure. After also successfully resetting the corresponding outgoingstream, which concludes the data channel closing initiated by the peer,a new DATA_CHANNEL_OPEN message can be sent on the stream.¶

After the DATA_CHANNEL_OPEN message has been sent, the sender of that messageMAY start sending messages containing user data withoutwaiting for the reception of the corresponding DATA_CHANNEL_ACK message.However, before the DATA_CHANNEL_ACK message or any other message has beenreceived on a data channel, all other messages containing user data andbelonging to this data channelMUST be sent ordered, no matterwhether the data channel is ordered or not.After the DATA_CHANNEL_ACK or any other message has been received on thedata channel, messages containing user dataMUST be sent ordered on ordereddata channels andMUST be sent unordered on unordered data channels.Therefore, receiving a message containing user data on an unused streamindicates an error. In that case, the corresponding data channelMUST be closed, as describedin[RFC8831].¶

8.IANA Considerations

IANA has updated the reference of an already existing SCTP PPIDassignment (Section 8.1) and created a newstandalone registry with its own URL for DCEP (Section 8.2) containing two newregistration tables (Sections8.2.1and8.2.2).¶

9.References

Acknowledgements

The authors wish to thankHarald Alvestrand,Richard Barnes,Adam Bergkvist,Spencer Dawkins,Barry Dingle,Stefan Håkansson,Cullen Jennings,Paul Kyzivat,Doug Leonard,Alexey Melnikov,Pete Resnick,Irene Rüngeler,Randall Stewart,Peter Thatcher,Martin Thomson,Justin Uberti,and many others for their invaluable comments.¶