draft-ietf-rtcweb-data-protocol-06.txt   draft-ietf-rtcweb-data-protocol-07.txt 
Network Working Group R. Jesup Network Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Loreto Intended status: Standards Track S. Loreto
Expires: December 11, 2014 Ericsson Expires: January 5, 2015 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
June 9, 2014 July 4, 2014
WebRTC Data Channel Establishment Protocol WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-06.txt draft-ietf-rtcweb-data-protocol-07.txt
Abstract Abstract
The Real-Time Communication in WEB-browsers working group is charged The WebRTC framework specifies protocol support for direct
to provide protocol support for direct interactive rich communication interactive rich communication using audio, video, and data between
using audio, video, and data between two peers' web-browsers. This two peers' web-browsers. This document specifies a simple protocol
document specifies a simple protocol for establishing symmetric data for establishing symmetric Data Channels between the peers. It uses
channels between the peers. It uses a two way handshake and allows a two way handshake and allows sending of user data without waiting
sending of user data without waiting for the handshake to complete. for the handshake to complete.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 11, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informational References . . . . . . . . . . . . . . . . 12 10.2. Informational References . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Data Channel Establishment Protocol (DCEP) is designed to The Data Channel Establishment Protocol (DCEP) is designed to
provide, in the WebRTC data channel context provide, in the WebRTC Data Channel context
[I-D.ietf-rtcweb-data-channel], a simple in-band method to open [I-D.ietf-rtcweb-data-channel], a simple in-band method to open
symmetric data channels. As discussed in symmetric Data Channels. As discussed in
[I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control
Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram
Transport Layer Security (DTLS) [RFC6347] as described in Transport Layer Security (DTLS) [RFC4347] as described in
[I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already
standardized transport and security features. standardized transport and security features.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the following terms: This document uses the following terms:
Association: An SCTP association. Association: An SCTP association.
Stream: A unidirectional stream of an SCTP association. It is Stream: A unidirectional stream of an SCTP association. It is
uniquely identified by an SCTP stream identifier (0-65534). Note: uniquely identified by an SCTP stream identifier (0-65534). Note:
the SCTP stream identifier 65535 is reserved due to SCTP INIT and the SCTP stream identifier 65535 is reserved due to SCTP INIT and
INIT-ACK chunks only allowing a maximum of 65535 streams to be INIT-ACK chunks only allowing a maximum of 65535 Streams to be
negotiated (0-65534). negotiated (0-65534).
Channel: Two Streams with the same SCTP stream identifier, one in 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. each direction, which are managed together.
4. Protocol Overview 4. Protocol Overview
The Data Channel Establishment Protocol is a simple, low-overhead way The Data Channel Establishment Protocol is a simple, low-overhead way
to establish bidirectional Channels over an SCTP association with a to establish bidirectional Data Channels over an SCTP association
consistent set of properties. with a consistent set of properties.
The set of consistent properties includes: The set of consistent properties includes:
o reliable or unreliable message transmission. In case of o reliable or unreliable message transmission. In case of
unreliable transmissions, the same level of unreliability is used. unreliable transmissions, the same level of unreliability is used.
o in-order or out-of-order message delivery. o in-order or out-of-order message delivery.
o the priority of the Channel. o the priority of the Data Channel.
o an optional label for the Channel. o an optional label for the Data Channel.
o an optional protocol for the Channel. o an optional protocol for the Data Channel.
o the SCTP streams. o the Streams.
This protocol uses a two way handshake to open a 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 handshake pairs one incoming and one outgoing Stream, both having the
having the same SCTP stream identifier, into a single bidirectional same Stream Identifier, into a single bidirectional Data Channel.
channel. The side wanting to open a data channel selects an SCTP The side wanting to open a Data Channel selects an Stream Identifier
stream identifier for which the corresponding incoming and outgoing for which the corresponding incoming and outgoing Streams are unused
SCTP streams are unused and sends a DATA_CHANNEL_OPEN message on the and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The
outgoing SCTP stream. The peer responds with a DATA_CHANNEL_ACK peer responds with a DATA_CHANNEL_ACK message on its corresponding
message on its corresponding outgoing SCTP stream. Then the data outgoing Stream. Then the Data Channel is open. Data Channel
channel is open. Data channel messages are sent on the same Stream Establishment Protocol messages are sent on the same Stream as the
as the user messages belonging to the data channel. The user messages belonging to the Data Channel. The demultiplexing is
demultiplexing is based on the SCTP payload protocol identifier based on the SCTP payload protocol identifier (PPID), since the Data
(PPID), since the Data Channel Establishment Protocol uses a specific Channel Establishment Protocol uses a specific PPID.
PPID.
Note: The opening side can send user messages before the Note: The opening side can send user messages before the
DATA_CHANNEL_ACK is received. DATA_CHANNEL_ACK is received.
To avoid glare in opening Channels, each side MUST use Streams with To avoid glare in opening Data Channels, each side MUST use Streams
either even or odd SCTP stream identifiers when sending a with either even or odd Stream Identifiers when sending a
DATA_CHANNEL_OPEN message. When using SCTP over DTLS DATA_CHANNEL_OPEN message. When using SCTP over DTLS
[I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which [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 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 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 Stream Identifiers, the side acting as the DTLS server MUST use
Streams with odd SCTP stream identifiers. Streams with odd Stream Identifiers.
Note: There is no attempt to resolve label glare; if both sides open 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 a Data Channel labeled "x" at the same time, there will be two Data
labeled "x" - one on an even Stream pair, one on an odd pair. Channels labeled "x" - one on an even Stream pair, one on an odd
pair.
The protocol field is to ease cross-application interoperation The protocol field is to ease cross-application interoperation
("federation") by identifying the user data being passed with an ("federation") by identifying the user data being passed with an
IANA-registered string ('WebSocket Subprotocol Name Registry' defined IANA-registered string ('WebSocket Subprotocol Name Registry' defined
in [RFC6455]), and may be useful for homogeneous applications which in [RFC6455]), and may be useful for homogeneous applications which
may create more than one type of Channel. Please note that there is may create more than one type of Data Channel. Please note that
also no attempt to resolve protocol glare. there is also no attempt to resolve protocol glare.
5. Message Formats 5. Message Formats
Every Data Channel Establishment Protocol message starts with a one Every Data Channel Establishment Protocol message starts with a one
byte field called "Message Type" which indicates the type of the byte field called "Message Type" which indicates the type of the
message. The corresponding values are managed by IANA (see message. The corresponding values are managed by IANA (see
Section 8.2). Section 8.2).
5.1. DATA_CHANNEL_OPEN Message 5.1. DATA_CHANNEL_OPEN Message
This message is sent initially on the stream used for user messages This message is sent initially on the Stream used for user messages
using the channel. using the Data Channel.
0 1 2 3 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 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 | | Message Type | Channel Type | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Parameter | | Reliability Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Length | Protocol Length | | Label Length | Protocol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 29 skipping to change at page 5, line 29
| Protocol | | Protocol |
/ \ / \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type: 1 byte (unsigned integer) Message Type: 1 byte (unsigned integer)
This field holds the IANA defined message type for the This field holds the IANA defined message type for the
DATA_CHANNEL_OPEN message. The suggested value of this field for DATA_CHANNEL_OPEN message. The suggested value of this field for
IANA is 0x03. IANA is 0x03.
Channel Type: 1 byte (unsigned integer) Channel Type: 1 byte (unsigned integer)
This field specifies the type of the channel to be opened and the This field specifies the type of the Data Channel to be opened and
values are managed by IANA (see Section 8.3): the values are managed by IANA (see Section 8.3):
DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable in- DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a
order bi-directional communication channel. reliable in-order bi-directional communication.
DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides
reliable unordered bi-directional communication channel. a reliable unordered bi-directional communication.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel
a partially-reliable in-order bi-directional communication provides a partially-reliable in-order bi-directional
channel. User messages will not be retransmitted more times communication. User messages will not be retransmitted more
than specified in the Reliability Parameter. times than specified in the Reliability Parameter.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The Data
channel provides a partial reliable unordered bi-directional Channel provides a partial reliable unordered bi-directional
communication channel. User messages will not be retransmitted communication. User messages will not be retransmitted more
more times than specified in the Reliability Parameter. times than specified in the Reliability Parameter.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The Data Channel
a partial reliable in-order bi-directional communication provides a partial reliable in-order bi-directional
channel. User messages might not be transmitted or communication. User messages might not be transmitted or
retransmitted after a specified life-time given in milli- retransmitted after a specified life-time given in milli-
seconds in the Reliability Parameter. This life-time starts seconds in the Reliability Parameter. This life-time starts
when providing the user message to the protocol stack. when providing the user message to the protocol stack.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The Data
provides a partial reliable unordered bi-directional Channel provides a partial reliable unordered bi-directional
communication channel. User messages might not be transmitted communication. User messages might not be transmitted or
or retransmitted after a specified life-time given in milli- retransmitted after a specified life-time given in milli-
seconds in the Reliability Parameter. This life-time starts seconds in the Reliability Parameter. This life-time starts
when providing the user message to the protocol stack. when providing the user message to the protocol stack.
Priority: 2 bytes (unsigned integer) Priority: 2 bytes (unsigned integer)
The priority of the channel as described in The priority of the Data Channel as described in
[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-rtcweb-data-channel].
Reliability Parameter: 4 bytes (unsigned integer) Reliability Parameter: 4 bytes (unsigned integer)
For reliable channels this field MUST be set to 0 on the sending For reliable Data Channels this field MUST be set to 0 on the
side and MUST be ignored on the receiving side. If a partial sending side and MUST be ignored on the receiving side. If a
reliable channel with limited number of retransmissions is used, partial reliable Data Channel with limited number of
this field specifies the number of retransmissions. If a partial retransmissions is used, this field specifies the number of
reliable channel with limited lifetime is used, this field retransmissions. If a partial reliable Data Channel with limited
specifies the maximum lifetime in milliseconds. The following lifetime is used, this field specifies the maximum lifetime in
table summarizes this: milliseconds. The following table summarizes this:
+------------------------------------------------+------------------+ +------------------------------------------------+------------------+
| Channel Type | Reliability | | Channel Type | Reliability |
| | Parameter | | | Parameter |
+------------------------------------------------+------------------+ +------------------------------------------------+------------------+
| DATA_CHANNEL_RELIABLE | Ignored | | DATA_CHANNEL_RELIABLE | Ignored |
| DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX |
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms |
+------------------------------------------------+------------------+ +------------------------------------------------+------------------+
Label Length: 2 bytes (unsigned integer) Label Length: 2 bytes (unsigned integer)
The length of the label field in bytes. The length of the label field in bytes.
Protocol Length: 2 bytes (unsigned integer) Protocol Length: 2 bytes (unsigned integer)
The length of the protocol field in bytes. The length of the protocol field in bytes.
Label: Variable Length (sequence of characters) Label: Variable Length (sequence of characters)
The name of the channel as a UTF-8 encoded string. This may be an The name of the Data Channel as a UTF-8 encoded string. This may
empty string. be an empty string.
Protocol: Variable Length (sequence of characters) Protocol: Variable Length (sequence of characters)
The sub-protocol for the channel as a UTF-8 encoded string. If If this is an empty string the protocol is unspecified. If it is
this is an empty string the protocol is unspecified. If it is a a non-empty string, it specifies a protocol registered in the
non-empty string, it specifies an protocol registered in the 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This
'WebSocket Subprotocol Name Registry' created in [RFC6455]. string is UTF-8 encoded.
5.2. DATA_CHANNEL_ACK Message 5.2. DATA_CHANNEL_ACK Message
This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE
message on the stream used for user messages using the channel. message on the stream used for user messages using the Data Channel.
Reception of this message tells the opener that the channel setup Reception of this message tells the opener that the Data Channel
handshake is complete. setup handshake is complete.
0 1 2 3 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 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 | | Message Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Message Type: 1 byte (unsigned integer) Message Type: 1 byte (unsigned integer)
This field holds the IANA defined message type for the This field holds the IANA defined message type for the
DATA_CHANNEL_ACK message. The suggested value of this field for DATA_CHANNEL_ACK message. The suggested value of this field for
IANA is 0x02. IANA is 0x02.
6. Procedures 6. Procedures
All Data Channel Establishment Protocol messages MUST be sent using All Data Channel Establishment Protocol messages MUST be sent using
ordered delivery and reliable transmission. They MUST be sent on the ordered delivery and reliable transmission. They MUST be sent on the
same outgoing SCTP stream as the user messages belonging to the same outgoing Stream as the user messages belonging to the
corresponding data channel. Multiplexing and demultiplexing is done corresponding Data Channel. Multiplexing and demultiplexing is done
by using the SCTP payload protocol identifier (PPID). Therefore Data by using the SCTP payload protocol identifier (PPID). Therefore Data
Channel Establishment Protocol message MUST be sent with the assigned Channel Establishment Protocol message MUST be sent with the assigned
PPID for the Data Channel Establishment Protocol (see Section 8.1). PPID for the Data Channel Establishment Protocol (see Section 8.1).
Other messages MUST NOT be sent using this PPID. Other messages MUST NOT be sent using this PPID.
If one side wants to open a data channel, it chooses an SCTP stream If one side wants to open a Data Channel, it chooses an Stream
identifier for which the corresponding incoming and outgoing SCTP identifier for which the corresponding incoming and outgoing Streams
streams are free. If the side is the DTLS client, it MUST choose an are free. If the side is the DTLS client, it MUST choose an even
even stream identifier, if the side is the DTLS server, it MUST Stream Identifier, if the side is the DTLS server, it MUST choose an
choose an odd one. It fills in the parameters of the odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message
DATA_CHANNEL_OPEN message and sends it on the chosen SCTP stream. and sends it on the chosen Stream.
After the DATA_CHANNEL_OPEN message has been sent, the sender of it After the DATA_CHANNEL_OPEN message has been sent, the sender of the
can start sending messages containing user data without waiting for DATA_CHANNEL_OPEN can start sending messages containing user data
the reception of the corresponding DATA_CHANNEL_ACK message. without waiting for the reception of the corresponding
However, before the DATA_CHANNEL_ACK message or any other message has DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK
been received on a data channel, all other messages containing user message or any other message has been received on a Data Channel, all
data and belonging to this data channel MUST be sent ordered, no other messages containing user data and belonging to this Data
matter whether the data channel is ordered or not. After the Channel MUST be sent ordered, no matter whether the Data Channel is
DATA_CHANNEL_ACK or any other message has been received on the data ordered or not. After the DATA_CHANNEL_ACK or any other message has
channel, messages containing user data MUST be send ordered on been received on the Data Channel, messages containing user data MUST
ordered data channels and MUST be sent unordered on unordered data be send ordered on ordered Data Channels and MUST be sent unordered
channels. Therefore receiving a message containing user data on an on unordered Data Channels. Therefore receiving a message containing
unused SCTP stream indicates an error. The corresponding channel user data on an unused Stream indicates an error. The corresponding
MUST be closed as described in [I-D.ietf-rtcweb-data-channel]. Data Channel MUST be closed as described in
[I-D.ietf-rtcweb-data-channel].
If a DATA_CHANNEL_OPEN message is received on an unused stream, the If a DATA_CHANNEL_OPEN message is received on an unused Stream, the
stream identifier corresponds to the role of the peer and all Stream Identifier corresponds to the role of the peer and all
parameters in the DATA_CHANNEL_OPEN message are valid, then a parameters in the DATA_CHANNEL_OPEN message are valid, then a
corresponding DATA_CHANNEL_ACK message is sent on the stream with the corresponding DATA_CHANNEL_ACK message is sent on the Stream with the
same stream identifier as the one the DATA_CHANNEL_OPEN message was same Stream Identifier as the one the DATA_CHANNEL_OPEN message was
received on. received on.
If a DATA_CHANNEL_OPEN message is received on an already used SCTP If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions
stream or there are any problems with parameters within the above, for instance if a DATA_CHANNEL_OPEN message is received on an
DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is already used Stream or there are any problems with parameters within
not well-formed, the receiver MUST close the corresponding channel the DATA_CHANNEL_OPEN message, the odd/even rule is violated or the
using the procedure described in [I-D.ietf-rtcweb-data-channel] and DATA_CHANNEL_OPEN message itself is not well-formed, the receiver
MUST NOT send a DATA_CHANNEL_ACK message in response to the received MUST close the corresponding Data Channel using the procedure
message. Therefore, receiving an SCTP stream reset request for a described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a
stream on which no DATA_CHANNEL_ACK message has been received DATA_CHANNEL_ACK message in response to the received message.
indicates to the sender of the corresponding DATA_CHANNEL_OPEN Therefore, receiving an SCTP stream reset request for a Stream on
message the failure of the data channel setup procedure. After also which no DATA_CHANNEL_ACK message has been received indicates to the
successfully resetting the corresponding outgoing SCTP stream, which sender of the corresponding DATA_CHANNEL_OPEN message the failure of
concludes the channel closing initiated by the peer, a new the Data Channel setup procedure. After also successfully resetting
DATA_CHANNEL_OPEN message can be sent on the stream. the corresponding outgoing Stream, which concludes the Data Channel
closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be
sent on the Stream.
7. Security Considerations 7. Security Considerations
The DATA_CHANNEL_OPEN messages contains two variable length fields: The DATA_CHANNEL_OPEN messages contains two variable length fields:
the protocol and the label. A receiver must be prepared to receive the protocol and the label. A receiver must be prepared to receive
DATA_CHANNEL_OPEN messages where these field have the maximum length DATA_CHANNEL_OPEN messages where these field have the maximum length
of 65535 bytes. Error cases like the use of inconsistent lengths of 65535 bytes. Error cases like the use of inconsistent lengths
fields, unknown parameter values or violation the odd/even rule must fields, unknown parameter values or violation the odd/even rule must
also be handled by closing the corresponding channel. An end-point also be handled by closing the corresponding Data Channel. An end-
must also be prepared that the peer open the maximum number of data point must also be prepared that the peer open the maximum number of
channels. Data Channels.
When using DCEP over SCTP encapsulated in DTLS as specified in This protocol does not provide privacy, integrity or authentication.
[I-D.ietf-tsvwg-sctp-dtls-encaps], security properties like privacy, It needs to be used as part of a protocol suite that contains all
integrity, and source authentication can be provided by DTLS. If these things. Such a protocol suite is specified in
DCEP is used without running over DTLS, this is not the case. [I-D.ietf-tsvwg-sctp-dtls-encaps].
For general considerations see [I-D.ietf-rtcweb-security] and For general considerations see [I-D.ietf-rtcweb-security] and
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor: [NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this "RFCXXXX" is to be replaced by the RFC number you assign this
document. document.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
future extensibility. future extensibility.
8.3. New Channel Type Registry 8.3. New Channel Type Registry
IANA is requested to create a new registration table "Channel Type IANA is requested to create a new registration table "Channel Type
Registry" for the Data Channel Establishment Protocol to manage the Registry" for the Data Channel Establishment Protocol to manage the
one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see
Section 5.1). Section 5.1).
The assignment of new message types is done through an RFC required The assignment of new message types is done through an RFC required
action, as defined in [RFC5226]. Documentation of the new channel action, as defined in [RFC5226]. Documentation of the new Channel
type MUST contain the following information: Type MUST contain the following information:
1. A name for the new channel type; 1. A name for the new Channel Type;
2. A detailed procedural description of the user message handling 2. A detailed procedural description of the user message handling
for data channels using this new channel type. for Data Channels using this new Channel Type.
Please note that if new channel types support ordered and unordered Please note that if new Channel Types support ordered and unordered
message delivery, the high order bit SHOULD be used to indicate message delivery, the high order bit SHOULD be used to indicate
whether the message delivery is unordered or not. whether the message delivery is unordered or not.
Initially the following values need to be registered: Initially the following values need to be registered:
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
| Name | Type | Reference | | Name | Type | Reference |
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
| DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] |
| DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] |
skipping to change at page 11, line 34 skipping to change at page 11, line 34
Thompson, Justin Uberti, and many others for their invaluable Thompson, Justin Uberti, and many others for their invaluable
comments. comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-04 (work in progress), May 2014. dtls-encaps-04 (work in progress), May 2014.
10.2. Informational References 10.2. Informational References
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, December 2011. 6455, December 2011.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-09 (work in Channels", draft-ietf-rtcweb-data-channel-10 (work in
progress), May 2014. progress), June 2014.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-06 (work in progress), January 2014. ietf-rtcweb-security-06 (work in progress), January 2014.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-09 (work in progress), February 2014. rtcweb-security-arch-09 (work in progress), February 2014.
Authors' Addresses Authors' Addresses
 End of changes. 48 change blocks. 
137 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/