draft-ietf-rtcweb-data-protocol-08.txt		draft-ietf-rtcweb-data-protocol-09.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: April 1, 2015 Ericsson		Expires: July 8, 2015 Ericsson
	M. Tuexen		M. Tuexen
	Muenster Univ. of Appl. Sciences		Muenster Univ. of Appl. Sciences
	September 28, 2014		January 4, 2015
	WebRTC Data Channel Establishment Protocol		WebRTC Data Channel Establishment Protocol
	draft-ietf-rtcweb-data-protocol-08.txt		draft-ietf-rtcweb-data-protocol-09.txt
	Abstract		Abstract
	The WebRTC framework specifies protocol support for direct		The WebRTC framework specifies protocol support for direct
	interactive rich communication using audio, video, and data between		interactive rich communication using audio, video, and data between
	two peers' web-browsers. This document specifies a simple protocol		two peers' web-browsers. This document specifies a simple protocol
	for establishing symmetric Data Channels between the peers. It uses		for establishing symmetric Data Channels between the peers. It uses
	a two way handshake and allows sending of user data without waiting		a two way handshake and allows sending of user data without waiting
	for the handshake to complete.		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 April 1, 2015.		This Internet-Draft will expire on July 8, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 39		skipping to change at page 2, line 39
	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) [RFC4347] as described in		Transport Layer Security (DTLS) 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. DTLS 1.0 is defined in
			[RFC4347] and the present latest version, DTLS 1.2, is defined in
			[RFC6347].
	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:
	skipping to change at page 3, line 47		skipping to change at page 3, line 47
	o an optional label for the Data Channel.		o an optional label for the Data Channel.
	o an optional protocol for the Data Channel.		o an optional protocol for the Data Channel.
	o the 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 Stream, both having the		handshake pairs one incoming and one outgoing Stream, both having the
	same Stream Identifier, into a single bidirectional Data Channel.		same Stream Identifier, into a single bidirectional Data Channel.
	The side wanting to open a Data Channel selects a Stream Identifier		The peer that initiates opening a Data Channel selects a Stream
	for which the corresponding incoming and outgoing Streams are unused		Identifier for which the corresponding incoming and outgoing Streams
	and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The		are unused and sends a DATA_CHANNEL_OPEN message on the outgoing
	peer responds with a DATA_CHANNEL_ACK message on its corresponding		Stream. The peer responds with a DATA_CHANNEL_ACK message on its
	outgoing Stream. Then the Data Channel is open. Data Channel		corresponding outgoing Stream. Then the Data Channel is open. Data
	Establishment Protocol messages are sent on the same Stream as the		Channel Establishment Protocol messages are sent on the same Stream
	user messages belonging to the Data Channel. The demultiplexing is		as the user messages belonging to the Data Channel. The
	based on the SCTP payload protocol identifier (PPID), since the Data		demultiplexing is based on the SCTP payload protocol identifier
	Channel Establishment Protocol uses a specific PPID.		(PPID), since the Data Channel Establishment Protocol uses a specific
			PPID.
	Note: The opening side can send user messages before the		Note: The opening side MAY send user messages before the
	DATA_CHANNEL_ACK is received.		DATA_CHANNEL_ACK is received.
	To avoid collisions where both sides try to open a Data Channel with		To avoid collisions where both sides try to open a Data Channel with
	the same Stream Identifiers, each side MUST use Streams with either		the same Stream Identifiers, each side MUST use Streams with either
	even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN		even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN
	message. When using SCTP over DTLS		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
	Stream Identifiers, the side acting as the DTLS server MUST use		Stream Identifiers, the side acting as the DTLS server MUST use
	skipping to change at page 6, line 46		skipping to change at page 6, line 46
	| 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 Data Channel as a UTF-8 encoded string. This may		The name of the Data Channel as a UTF-8 encoded string as
	be an empty string.		specified in [RFC3629]. This may be an empty string.
	Protocol: Variable Length (sequence of characters)		Protocol: Variable Length (sequence of characters)
	If this is an empty string the protocol is unspecified. If it is		If this is an empty string the protocol is unspecified. If it is
	a non-empty string, it specifies a protocol registered in the		a non-empty string, it specifies a protocol registered in the
	'WebSocket Subprotocol Name Registry' created in [RFC6455]. This		'WebSocket Subprotocol Name Registry' created in [RFC6455]. This
	string is UTF-8 encoded.		string is UTF-8 encoded as specified in [RFC3629].
	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 Data Channel.		message on the stream used for user messages using the Data Channel.
	Reception of this message tells the opener that the Data Channel		Reception of this message tells the opener that the Data Channel
	setup 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
	skipping to change at page 7, line 36		skipping to change at page 7, line 36
	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 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 a Stream		The peer that initiates opening a Data Channel selects a Stream
	Identifier for which the corresponding incoming and outgoing Streams		Identifier for which the corresponding incoming and outgoing Streams
	are free. If the side is the DTLS client, it MUST choose an even		are unused. 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		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		odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message
	and sends it on the chosen Stream.		and sends it on the chosen Stream.
	After the DATA_CHANNEL_OPEN message has been sent, the sender of the
	DATA_CHANNEL_OPEN 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 Stream indicates an error. The corresponding
	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 the DATA_CHANNEL_OPEN message doesn't satisfy the conditions		If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions
	above, for instance if a DATA_CHANNEL_OPEN message is received on an		above, for instance if a DATA_CHANNEL_OPEN message is received on an
	already used Stream or there are any problems with parameters within		already used Stream or there are any problems with parameters within
	skipping to change at page 8, line 33		skipping to change at page 8, line 18
	described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a		described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a
	DATA_CHANNEL_ACK message in response to the received message.		DATA_CHANNEL_ACK message in response to the received message.
	Therefore, receiving an SCTP stream reset request for a Stream on		Therefore, receiving an SCTP stream reset request for a Stream on
	which no DATA_CHANNEL_ACK message has been received indicates to the		which no DATA_CHANNEL_ACK message has been received indicates to the
	sender of the corresponding DATA_CHANNEL_OPEN message the failure of		sender of the corresponding DATA_CHANNEL_OPEN message the failure of
	the Data Channel setup procedure. After also successfully resetting		the Data Channel setup procedure. After also successfully resetting
	the corresponding outgoing Stream, which concludes the Data Channel		the corresponding outgoing Stream, which concludes the Data Channel
	closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be		closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be
	sent on the Stream.		sent on the Stream.
			After the DATA_CHANNEL_OPEN message has been sent, the sender of the
			DATA_CHANNEL_OPEN MAY 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 sent ordered on ordered Data Channels and MUST be sent unordered
			on unordered Data Channels. Therefore receiving a message containing
			user data on an unused Stream indicates an error. The corresponding
			Data Channel MUST be closed as described in
			[I-D.ietf-rtcweb-data-channel].
	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 Data Channel. An end-		also be handled by closing the corresponding Data Channel. An end-
	point must also be prepared that the peer open the maximum number of		point must also be prepared that the peer open the maximum number of
	Data Channels.		Data Channels.
	skipping to change at page 11, line 6		skipping to change at page 11, line 6
	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 MUST be used to indicate whether
	whether the message delivery is unordered or not.		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] |
	| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] |		| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] |
	| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] |		| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] |
	skipping to change at page 11, line 32		skipping to change at page 11, line 32
	| Unassigned | rest | |		| Unassigned | rest | |
	+------------------------------------------------+------+-----------+		+------------------------------------------------+------+-----------+
	Please note that the values 0x7f and 0xff have been reserved for		Please note that the values 0x7f and 0xff have been reserved for
	future extensibility. The range of possible values is from 0x00 to		future extensibility. The range of possible values is from 0x00 to
	0xff.		0xff.
	9. Acknowledgments		9. Acknowledgments
	The authors wish to thank Harald Alvestrand, Richard Barnes, Adam		The authors wish to thank Harald Alvestrand, Richard Barnes, Adam
	Bergkvist, Barry Dingle, Stefan Haekansson, Cullen Jennings, Paul		Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Haekansson, Cullen
	Kyzivat, Doug Leonard, Irene Ruengeler, Randall Stewart, Peter		Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick,
	Thatcher, Martin Thompson, Justin Uberti, and many others for their		Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson,
	invaluable comments.		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.
			[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, November 2003.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		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-05 (work in progress), July 2014.		dtls-encaps-07 (work in progress), December 2014.
	[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-11 (work in		Channels", draft-ietf-rtcweb-data-channel-12 (work in
	progress), July 2014.		progress), September 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-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", draft-		Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-07 (work in progress), July 2014.		ietf-rtcweb-security-07 (work in progress), July 2014.
End of changes. 21 change blocks.
	46 lines changed or deleted		55 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/