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/