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/