draft-ietf-rtcweb-data-protocol-05.txt   draft-ietf-rtcweb-data-protocol-06.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: November 16, 2014 Ericsson Expires: December 11, 2014 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
May 15, 2014 June 9, 2014
WebRTC Data Channel Establishment Protocol WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-05.txt draft-ietf-rtcweb-data-protocol-06.txt
Abstract Abstract
The Real-Time Communication in WEB-browsers working group is charged The Real-Time Communication in WEB-browsers working group is charged
to provide protocol support for direct interactive rich communication to provide protocol support for direct interactive rich communication
using audio, video, and data between two peers' web-browsers. This using audio, video, and data between two peers' web-browsers. This
document specifies a simple protocol for establishing symmetric data document specifies a simple protocol for establishing symmetric data
channels between the peers. It uses a two way handshake and allows channels between the peers. It uses a two way handshake and allows
sending of user data without waiting for the handshake to complete. sending of user data without waiting for the handshake to complete.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 November 16, 2014. This Internet-Draft will expire on December 11, 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 27 skipping to change at page 2, line 27
5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9
8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . 11 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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
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 Channel: Two Streams with the same SCTP stream identifier, one in
each direction, which are managed together. each direction, which are managed together.
4. Protocol Overview 4. Protocol Overview
This protocol is a simple, low-overhead way to establish The Data Channel Establishment Protocol is a simple, low-overhead way
bidirectional Channels over an SCTP association with a consistent set to establish bidirectional Channels over an SCTP association with a
of properties. consistent set of properties.
The set of consistent properties includes: The set of consistent properties includes:
o whether the messages are transmitted reliable or unreliable. In o reliable or unreliable message transmission. In case of
case of unreliable transmissions, the same level of unreliability unreliable transmissions, the same level of unreliability is used.
is used.
o whether the messages are delivered in-order or out-of order. o in-order or out-of-order message delivery.
o the priority of the Channel. o the priority of the Channel.
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 Establishment Protocol uses a two way handshake to This protocol uses a two way handshake to open a data channel. The
open a data channel by combining two SCTP streams, one in each handshake pairs one incoming and one outgoing SCTP stream, both
direction, with the same SCTP stream identifier. The side wanting to having the same SCTP stream identifier, into a single bidirectional
open a data channel selects an SCTP stream identifier for which the channel. The side wanting to open a data channel selects an SCTP
corresponding incoming and outgoing SCTP streams are unused and sends stream identifier for which the corresponding incoming and outgoing
a DATA_CHANNEL_OPEN message on the outgoing SCTP stream. The peer SCTP streams are unused and sends a DATA_CHANNEL_OPEN message on the
responds with a DATA_CHANNEL_ACK message on its corresponding outgoing SCTP stream. The peer responds with a DATA_CHANNEL_ACK
outgoing SCTP stream. Then the data channel is open. Please note message on its corresponding outgoing SCTP stream. Then the data
that the opening side can send user messages before the channel is open. Data channel messages are sent on the same Stream
DATA_CHANNEL_ACK is received. Data channel messages are sent on the 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 Establishment Protocol uses a specific (PPID), since the Data Channel Establishment Protocol uses a specific
PPID. PPID.
Note: The opening side can send user messages before the
DATA_CHANNEL_ACK is received.
To avoid glare in opening Channels, each side MUST use Streams with To avoid glare in opening Channels, each side MUST use Streams with
either even or odd SCTP stream identifiers when sending a either even or odd SCTP stream identifiers when sending a
DATA_CHANNEL_OPEN message. When using 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 SCTP stream identifiers, the side acting as the DTLS server MUST use
Streams with odd SCTP stream identifiers. Streams with odd SCTP 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.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel
provides a partial reliable unordered bi-directional provides a partial reliable unordered bi-directional
communication channel. User messages might not be transmitted communication channel. User messages might not be transmitted
or retransmitted after a specified life-time given in milli- or 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 channel as described in
[I-D.ietf-rtcweb-data-channel]. The higher the number, the lower [I-D.ietf-rtcweb-data-channel].
the priority.
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 channels this field MUST be set to 0 on the sending
side and MUST be ignored on the receiving side. If a partial side and MUST be ignored on the receiving side. If a partial
reliable channel with limited number of retransmissions is used, reliable channel with limited number of retransmissions is used,
this field specifies the number of retransmissions. If a partial this field specifies the number of retransmissions. If a partial
reliable channel with limited lifetime is used, this field reliable channel with limited lifetime is used, this field
specifies the maximum lifetime in milliseconds. The following specifies the maximum lifetime in milliseconds. The following
table summarizes this: table summarizes this:
skipping to change at page 11, line 22 skipping to change at page 11, 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 | |
+------------------------------------------------+------+-----------+ +------------------------------------------------+------+-----------+
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry
Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Irene Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Doug
Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, Justin Leonard, Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin
Uberti, and many others for their invaluable comments. Thompson, Justin Uberti, and many others for their 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.
skipping to change at page 12, line 7 skipping to change at page 12, line 12
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-08 (work in Channels", draft-ietf-rtcweb-data-channel-09 (work in
progress), April 2014. progress), May 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. 14 change blocks. 
31 lines changed or deleted 32 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/