draft-ietf-rtcweb-data-protocol-02.txt   draft-ietf-rtcweb-data-protocol-03.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: August 13, 2014 Ericsson Expires: August 15, 2014 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
February 9, 2014 February 11, 2014
WebRTC Data Channel Protocol WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-02.txt draft-ietf-rtcweb-data-protocol-03.txt
Abstract Abstract
The Web Real-Time Communication (WebRTC) working group is charged to The Web Real-Time Communication (WebRTC) working group is charged to
provide protocols to support for direct interactive rich provide protocols to support for direct interactive rich
communication using audio, video, and data between two peers' web- communication using audio, video, and data between two peers' web-
browsers. This document specifies a simple protocol for establishing browsers. This document specifies a simple protocol for establishing
symmetric data channels between the peers. It uses a two way symmetric data channels between the peers. It uses a two way
handshake and allows sending of user data without waiting for the handshake and allows sending of user data without waiting for the
handshake to complete. handshake to complete.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 13, 2014. This Internet-Draft will expire on August 15, 2014.
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 34 skipping to change at page 2, line 34
8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9
8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informational References . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The data channel protocol is designed to provide, in the WebRTC data The Data Channel Establishment Protocol (DCEP) is designed to
channel context [I-D.ietf-rtcweb-data-channel], a simple in-band provide, in the WebRTC data channel context
method to open symmetric data channels. As discussed in [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 [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) [RFC6347] 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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
is used. is used.
o whether the messages are delivered in-order or out-of order. o whether the messages are delivered in-order or out-of order.
o an optional label for the Channel. o an optional label for the Channel.
o an optional protocol for the Channel. o an optional protocol for the Channel.
o the SCTP streams. o the SCTP streams.
The data channel protocol uses a two way handshake to open a data The Data Channel Establishment Protocol uses a two way handshake to
channel by combining two SCTP streams, one in each direction, with open a data channel by combining two SCTP streams, one in each
the same SCTP stream identifier. The side wanting to open a data direction, with the same SCTP stream identifier. The side wanting to
channel selects an SCTP stream identifier for which the corresponding open a data channel selects an SCTP stream identifier for which the
incoming and outgoing SCTP stream is unused and sends a corresponding incoming and outgoing SCTP stream is unused and sends a
DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer
responds with a DATA_CHANNEL_ACK message on its corresponding responds with a DATA_CHANNEL_ACK message on its corresponding
outgoing SCTP stream. Then the data channel is open. Please note outgoing SCTP stream. Then the data channel is open. Please note
that the opening side can send user messages before the that the opening side can send user messages before the
DATA_CHANNEL_ACK is received. Data channel messages are sent on 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 same Stream as the user messages belonging to the data channel. The
demultiplexing is based on the SCTP payload protocol identifier demultiplexing is based on the SCTP payload protocol identifier
(PPID), since the data channel protocol uses a specific PPID. (PPID), since the Data Channel Establishment Protocol uses a specific
PPID.
To avoid glare in opening Channels, each side MUST use either even or To avoid glare in opening Channels, each side MUST use either even or
odd Streams when sending a DATA_CHANNEL_OPEN message. The method odd Streams when sending a DATA_CHANNEL_OPEN message. The method
used to determine which side uses odd or even is based on the used to determine which side uses odd or even is based on the
underlying DTLS connection role when used in WebRTC, with the side underlying DTLS connection role when used in WebRTC, with the side
acting as the DTLS client using even stream identifiers. acting as the DTLS client using even 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 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. 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 (see Section 8.4), and may be useful for IANA-registered string (see Section 8.4), and may be useful for
homogenous applications which may create more than one type of homogenous applications which may create more than one type of
Channel. Channel.
5. Message Formats 5. Message Formats
Every data channel protocol message starts with a one byte field Every Data Channel Establishment Protocol message starts with a one
called "Message Type" which indicates the type of the message. The byte field called "Message Type" which indicates the type of the
corresponding values are managed by IANA (see Section 8.2). message. The corresponding values are managed by IANA (see
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 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 |
skipping to change at page 7, line 7 skipping to change at page 7, line 7
| 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 the This field holds the IANA defined message type for the 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 protocol messages MUST be sent requesting ordered All Data Channel Establishment Protocol messages MUST be sent
delivery and using reliable transmission. They MUST be sent on the requesting ordered delivery and using reliable transmission. They
same outgoing SCTP stream as the user messages belonging to the MUST be sent on the same outgoing SCTP stream as the user messages
corresponding data channel. Multiplexing and demultiplexing is done belonging to the corresponding data channel. Multiplexing and
by using the SCTP payload protocol identifier (PPID). Therefore data demultiplexing is done by using the SCTP payload protocol identifier
channel protocol message MUST be sent with the assigned PPID for the (PPID). Therefore Data Channel Establishment Protocol message MUST
data channel protocol (see Section 8.1). Other message MUST NOT be be sent with the assigned PPID for the Data Channel Establishment
sent using this PPID. Protocol (see Section 8.1). Other message MUST NOT be sent using
this PPID.
If one sides wants to open a data channel, it chooses a free outgoing If one sides wants to open a data channel, it chooses an SCTP stream
SCTP stream. If the side is the DTLS client, it MUST choose an even identifier for which the corresponding incoming and outgoing SCTP
stream identifier, if the side is the DTLS server, it MUST choose an streams are free. If the side is the DTLS client, it MUST choose an
odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message even stream identifier, if the side is the DTLS server, it MUST
and sends it on the chosen SCTP stream. choose an odd one. It fills in the parameters of the
DATA_CHANNEL_OPEN message and sends it on the chosen SCTP 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 it
can start sending messages containing user data without waiting for can start sending messages containing user data without waiting for
the reception of the corresponding DATA_CHANNEL_ACK message. the reception of the corresponding DATA_CHANNEL_ACK message.
However, before the DATA_CHANNEL_ACK message or any other message has However, before the DATA_CHANNEL_ACK message or any other message has
been received on the data channel, all other messages containing user been received on the data channel, all other messages containing user
data and belonging to the data channel MUST be sent ordered, not data and belonging to the data channel MUST be sent ordered, not
matter whether the data channel is ordered or not. After the matter whether the data channel is ordered or not. After the
DATA_CHANNEL_ACK or any other message has been received on the data DATA_CHANNEL_ACK or any other message has been received on the data
channel, messages containing user data MUST be send ordered on channel, messages containing user data MUST be send ordered on
skipping to change at page 8, line 23 skipping to change at page 8, line 25
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.
] ]
IANA is asked to update the reference of an already existing SCTP IANA is asked to update the reference of an already existing SCTP
PPID assignment and to create three new registries for the data PPID assignment and to create three new registries for the Data
channel protocol. Channel Establishment Protocol.
8.1. SCTP Payload Protocol Identifier 8.1. SCTP Payload Protocol Identifier
This document uses one already registered SCTP Payload Protocol This document uses one already registered SCTP Payload Protocol
Identifier (PPID). [RFC4960] creates the registry "SCTP Payload Identifier (PPID) named "WebRTC Control". [RFC4960] creates the
Protocol Identifiers" from which this identifier was assigned. IANA registry "SCTP Payload Protocol Identifiers" from which this
is requested to update the reference of this assignment to point to identifier was assigned. IANA is requested to update the reference
this document. Therefore this assignment should be updated to read: of this assignment to point to this document and to update the name.
Therefore this assignment should be updated to read:
+----------------+-----------+-----------+ +-------------+-----------+-----------+
| Value | SCTP PPID | Reference | | Value | SCTP PPID | Reference |
+----------------+-----------+-----------+ +-------------+-----------+-----------+
| WebRTC Control | 50 | [RFCXXXX] | | WebRTC DCEP | 50 | [RFCXXXX] |
+----------------+-----------+-----------+ +-------------+-----------+-----------+
8.2. New Message Type Registry 8.2. New Message Type Registry
IANA is requested to create a new registration table "Message Type IANA is requested to create a new registration table "Message Type
Registry" for the data channel protocol to manage the one byte Registry" for the Data Channel Establishment Protocol (DCEP) to
"Message Type" field in data channel messages (see Section 5). manage the one byte "Message Type" field in DCEP messages (see
Section 5).
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 message action, as defined in [RFC5226]. Documentation of the new message
type MUST contain the following information: type MUST contain the following information:
1. A name for the new message type; 1. A name for the new message type;
2. A detailed procedural description of the use of messages with the 2. A detailed procedural description of the use of messages with the
new type within the operation of the data channel protocol. new type within the operation of the Data Channel Establishment
Protocol.
Initially the following values need to be registered: Initially the following values need to be registered:
+-------------------+-----------+-----------+ +-------------------+-----------+-----------+
| Name | Type | Reference | | Name | Type | Reference |
+-------------------+-----------+-----------+ +-------------------+-----------+-----------+
| Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x00 | [RFCXXXX] |
| Reserved | 0x01 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] |
| DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] |
| DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] |
skipping to change at page 9, line 27 skipping to change at page 9, line 35
| Reserved | 0xff | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] |
+-------------------+-----------+-----------+ +-------------------+-----------+-----------+
Please note that the values 0x00 and 0x01 are reserved to avoid Please note that the values 0x00 and 0x01 are reserved to avoid
interoperability problems, since they have been used in earlier interoperability problems, since they have been used in earlier
versions of the document. versions of the document.
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 protocol to manage the one byte Registry" for the Data Channel Establishment Protocol to manage the
"Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see
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.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] |
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] |
| Reserved | 0x7f | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] |
| Reserved | 0xff | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] |
| Unassigned | rest | | | Unassigned | rest | |
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
8.4. New Protocol Registry 8.4. New Protocol Registry
IANA is requested to create a new registration table "Protocol IANA is requested to create a new registration table "Protocol
Registry" for the data channel protocol to manage the "Protocol" Registry" for the Data Channel Establishment Protocol to manage the
field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1). "Protocol" field of type string in DATA_CHANNEL_OPEN messages (see
Section 5.1).
The assignment of new message types is done through an First Come The assignment of new message types is done through an First Come
First Served action, as defined in [RFC5226]. Documentation of the First Served action, as defined in [RFC5226]. Documentation of the
new protocol MUST contain the following information: new protocol MUST contain the following information:
1. A name for the protocol; 1. A name for the protocol;
2. A reference for the protocol indicated by the registered string. 2. A reference for the protocol indicated by the registered string.
Initially this registry is empty. Initially this registry is empty.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Martin Thompson, Cullen Jennings, Harald The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry
Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall Dingle, Stefan Haekansson, Cullen Jennings, Randall Stewart, Peter
Stewart, Stefan Haekansson and many others for their invaluable Thatcher, Martin Thompson, Justin Uberti, and many others for their
comments. invaluable 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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
 End of changes. 19 change blocks. 
52 lines changed or deleted 63 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/