draft-ietf-rtcweb-data-channel-04.txt		draft-ietf-rtcweb-data-channel-05.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 29, 2013 Ericsson		Expires: January 16, 2014 Ericsson
	M. Tuexen		M. Tuexen
	Muenster Univ. of Appl. Sciences		Muenster Univ. of Appl. Sciences
	February 25, 2013		July 15, 2013
	RTCWeb Data Channels		RTCWeb Data Channels
	draft-ietf-rtcweb-data-channel-04.txt		draft-ietf-rtcweb-data-channel-05.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 protocol support for direct interactive rich communication		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 the non-media data transport aspects of the WebRTC		document specifies the non-media data transport aspects of the WebRTC
	framework. It provides an architectural overview of how the Stream		framework. It provides an architectural overview of how the Stream
	Control Transmission Protocol (SCTP) is used in the WebRTC context as		Control Transmission Protocol (SCTP) is used in the WebRTC context as
	a generic transport service allowing Web Browser to exchange generic		a generic transport service allowing Web Browser to exchange generic
	data from peer to peer.		data from peer to peer.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 29, 2013.		This Internet-Draft will expire on January 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Use Cases for Unreliable Data Channels . . . . . . . . . . 4		3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 3
	3.2. Use Cases for Reliable Data Channels . . . . . . . . . . . 4		3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 3
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . . 6		5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5
	6. The Usage of SCTP in the RTCWeb Context . . . . . . . . . . . 9		6. The Usage of SCTP in the RTCWeb Context . . . . . . . . . . . 8
	6.1. Association Setup . . . . . . . . . . . . . . . . . . . . 9		6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8
	6.2. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . . 9		6.2. Association Setup . . . . . . . . . . . . . . . . . . . . 9
	6.3. Channel Definition . . . . . . . . . . . . . . . . . . . . 9		6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9
	6.4. Usage of Payload Protocol Identifier . . . . . . . . . . . 10		6.4. Channel Definition . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6.5. Usage of Payload Protocol Identifier . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Non-media data types in the context of RTCWeb are handled by using		Non-media data types in the context of RTCWeb are handled by using
	SCTP [RFC4960] encapsulated in DTLS [RFC6347].		SCTP [RFC4960] encapsulated in DTLS [RFC6347].
	+----------+		+----------+
	| SCTP |		| SCTP |
	+----------+		+----------+
	| DTLS |		| DTLS |
	+----------+		+----------+
	| ICE/UDP |		| ICE/UDP |
	+----------+		+----------+
	Figure 1: Basic stack diagram		Figure 1: Basic stack diagram
	The encapsulation of SCTP over DTLS (see		The encapsulation of SCTP over DTLS (see
	[I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245])		[I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245])
	provides a NAT traversal solution together with confidentiality,		provides a NAT traversal solution together with confidentiality,
	source authentication, and integrity protected transfers. This data		source authentication, and integrity protected transfers. This data
	transport service operates in parallel to the media transports, and		transport service operates in parallel to the media transports, and
	all of them can eventually share a single transport-layer port		all of them can eventually share a single transport-layer port
	number.		number.
	skipping to change at page 4, line 8		skipping to change at page 3, line 34
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Use Cases		3. Use Cases
	This section defined use cases specific to data channels. For		This section defined use cases specific to data channels. For
	general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements].		general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements].
	3.1. Use Cases for Unreliable Data Channels		3.1. Use Cases for Unreliable Data Channels
	U-C 1 A real-time game where position and object state information		U-C 1 A real-time game where position and object state information
	is sent via one or more unreliable data channels. Note that		is sent via one or more unreliable data channels. Note that at
	at any time there may be no media channels, or all media		any time there may be no media channels, or all media channels may
	channels may be inactive, and that there may also be reliable		be inactive, and that there may also be reliable data channels in
	data channels in use.		use.
	U-C 2 Providing non-critical information to a user about the reason		U-C 2 Providing non-critical information to a user about the reason
	for a state update in a video chat or conference, such as Mute		for a state update in a video chat or conference, such as Mute
	state.		state.
	3.2. Use Cases for Reliable Data Channels		3.2. Use Cases for Reliable Data Channels
	U-C 3 A real-time game where critical state information needs to be		U-C 3 A real-time game where critical state information needs to be
	transferred, such as control information. Such a game may		transferred, such as control information. Such a game may have no
	have no media channels, or they may be inactive at any given		media channels, or they may be inactive at any given time, or may
	time, or may only be added due to in-game actions.		only be added due to in-game actions.
	U-C 4 Non-realtime file transfers between people chatting. Note		U-C 4 Non-realtime file transfers between people chatting. Note
	that this may involve a large number of files to transfer		that this may involve a large number of files to transfer
	sequentially or in parallel, such as when sharing a folder of		sequentially or in parallel, such as when sharing a folder of
	images or a directory of files.		images or a directory of files.
	U-C 5 Realtime text chat while talking with an individual or with		U-C 5 Realtime text chat while talking with an individual or with
	multiple people in a conference.		multiple people in a conference.
	U-C 6 Renegotiation of the set of media streams in the		U-C 6 Renegotiation of the set of media streams in the
	PeerConnection.		PeerConnection.
	U-C 7 Proxy browsing, where a browser uses data channels of a		U-C 7 Proxy browsing, where a browser uses data channels of a
	PeerConnection to send and receive HTTP/HTTPS requests and		PeerConnection to send and receive HTTP/HTTPS requests and data,
	data, for example to avoid local internet filtering or		for example to avoid local internet filtering or monitoring.
	monitoring.
	4. Requirements		4. Requirements
	This section lists the requirements for P2P data channels between two		This section lists the requirements for P2P data channels between two
	browsers.		browsers.
	Req. 1 Multiple simultaneous data channels MUST be supported. Note		Req. 1 Multiple simultaneous data channels MUST be supported. Note
	that there may 0 or more media streams in parallel with the		that there may 0 or more media streams in parallel with the data
	data channels, and the number and state (active/inactive) of		channels, and the number and state (active/inactive) of the media
	the media streams may change at any time.		streams may change at any time.
	Req. 2 Both reliable and unreliable data channels MUST be		Req. 2 Both reliable and unreliable data channels MUST be
	supported.		supported.
	Req. 3 Data channels MUST be congestion controlled; either		Req. 3 Data channels MUST be congestion controlled; either
	individually, as a class, or in conjunction with the media		individually, as a class, or in conjunction with the media
	streams, to ensure that data channels don't cause congestion		streams, to ensure that data channels don't cause congestion
	problems for the media streams, and that the RTCWeb		problems for the media streams, and that the RTCWeb PeerConnection
	PeerConnection as a whole is fair with competing traffic		as a whole is fair with competing traffic such as TCP.
	such as TCP.
	Req. 4 The application SHOULD be able to provide guidance as to the		Req. 4 The application SHOULD be able to provide guidance as to the
	relative priority of each data channel relative to each		relative priority of each data channel relative to each other, and
	other, and relative to the media streams. [ TBD: how this is		relative to the media streams. [ TBD: how this is encoded and
	encoded and what the impact of this is. ] This will interact		what the impact of this is. ] This will interact with the
	with the congestion control algorithms.		congestion control algorithms.
	Req. 5 Data channels MUST be secured; allowing for confidentiality,		Req. 5 Data channels MUST be secured; allowing for confidentiality,
	integrity and source authentication. See		integrity and source authentication. See
	[I-D.ietf-rtcweb-security] and		[I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch] for
	[I-D.ietf-rtcweb-security-arch] for detailed info.		detailed info.
	Req. 6 Data channels MUST provide message fragmentation support		Req. 6 Data channels MUST provide message fragmentation support
	such that IP-layer fragmentation can be avoided no matter		such that IP-layer fragmentation can be avoided no matter how
	how large a message the Javascript application passes to be		large a message the Javascript application passes to be sent. It
	sent. It also MUST ensure that large data channel transfers		also MUST ensure that large data channel transfers don't unduely
	don't unduely delay traffic on other data channels.		delay traffic on other data channels.
	Req. 7 The data channel transport protocol MUST NOT encode local IP		Req. 7 The data channel transport protocol MUST NOT encode local IP
	addresses inside its protocol fields; doing so reveals		addresses inside its protocol fields; doing so reveals potentially
	potentially private information, and leads to failure if the		private information, and leads to failure if the address is
	address is depended upon.		depended upon.
	Req. 8 The data channel transport protocol SHOULD support		Req. 8 The data channel transport protocol SHOULD support
	unbounded-length "messages" (i.e., a virtual socket stream)		unbounded-length "messages" (i.e., a virtual socket stream) at the
	at the application layer, for such things as image-file-		application layer, for such things as image-file-transfer;
	transfer; Implementations might enforce a reasonable message		Implementations might enforce a reasonable message size limit.
	size limit.
	Req. 9 The data channel transport protocol SHOULD avoid IP		Req. 9 The data channel transport protocol SHOULD avoid IP
	fragmentation. It MUST support PMTU discovery and MUST NOT		fragmentation. It MUST support PMTU discovery and MUST NOT rely
	rely on ICMP or ICMPv6 being generated or being passed back,		on ICMP or ICMPv6 being generated or being passed back, especially
	especially for PMTU discovery.		for PMTU discovery.
	Req. 10 It MUST be possible to implement the protocol stack in the		Req. 10 It MUST be possible to implement the protocol stack in the
	user application space.		user application space.
	5. SCTP over DTLS over UDP Considerations		5. SCTP over DTLS over UDP Considerations
	The important features of SCTP in the RTCWeb context are:		The important features of SCTP in the RTCWeb context are:
	o TCP-friendly congestion control.		o TCP-friendly congestion control.
	o The congestion control is modifiable for integration with media		o The congestion control is modifiable for integration with media
	stream congestion control.		stream congestion control.
	skipping to change at page 7, line 5		skipping to change at page 6, line 23
	Each SCTP user message contains a so called Payload Protocol		Each SCTP user message contains a so called Payload Protocol
	Identifier (PPID) that is passed to SCTP by its upper layer and sent		Identifier (PPID) that is passed to SCTP by its upper layer and sent
	to its peer. This value can be used to multiplex multiple protocols		to its peer. This value can be used to multiplex multiple protocols
	over a single SCTP association. The sender provides for each		over a single SCTP association. The sender provides for each
	protocol a specific PPID and the receiver can demultiplex the		protocol a specific PPID and the receiver can demultiplex the
	messages based on the received PPID.		messages based on the received PPID.
	The encapsulation of SCTP over DTLS, together with the SCTP features		The encapsulation of SCTP over DTLS, together with the SCTP features
	listed above satisfies all the requirements listed in Section 4.		listed above satisfies all the requirements listed in Section 4.
	The layering of protocols for WebRTC is shown in the following		The layering of protocols for WebRTC is shown in the following Figure
	Figure 2.		2.
	+------+		+------+
	|RTCWEB|		|RTCWEB|
	| DATA |		| DATA |
	+------+		+------+
	| SCTP |		| SCTP |
	+--------------------+		+--------------------+
	| STUN | SRTP | DTLS |		| STUN | SRTP | DTLS |
	+--------------------+		+--------------------+
	| ICE |		| ICE |
	+--------------------+		+--------------------+
	| UDP1 | UDP2 | ... |		| UDP1 | UDP2 | ... |
	+--------------------+		+--------------------+
	Figure 2: WebRTC protocol layers		Figure 2: WebRTC protocol layers
	This stack (especially in contrast to DTLS over SCTP [RFC6083] in		This stack (especially in contrast to DTLS over SCTP [RFC6083] in
	combination with SCTP over UDP [I-D.ietf-tsvwg-sctp-udp-encaps]) has		combination with SCTP over UDP [RFC6951]) has been chosen because it
	been chosen because it
	o supports the transmission of arbitrary large user messages.		o supports the transmission of arbitrary large user messages.
	o shares the DTLS connection with the media channels.		o shares the DTLS connection with the media channels.
	o provides privacy for the SCTP control information.		o provides privacy for the SCTP control information.
	Considering the protocol stack of Figure 2 the usage of DTLS over UDP		Considering the protocol stack of Figure 2 the usage of DTLS over UDP
	is specified in [RFC6347], while the usage of SCTP on top of DTLS is		is specified in [RFC6347], while the usage of SCTP on top of DTLS is
	specified in [I-D.ietf-tsvwg-sctp-dtls-encaps].		specified in [I-D.ietf-tsvwg-sctp-dtls-encaps].
	skipping to change at page 9, line 7		skipping to change at page 8, line 26
	channel transfer ending up with most or all the channel bandwidth.		channel transfer ending up with most or all the channel bandwidth.
	Since SCTP does not support the negotiation of a congestion control		Since SCTP does not support the negotiation of a congestion control
	algorithm, the algorithm either MUST be negotiated before		algorithm, the algorithm either MUST be negotiated before
	establishment of the SCTP association or MUST NOT require any		establishment of the SCTP association or MUST NOT require any
	negotiation because it only requires sender side behavior using		negotiation because it only requires sender side behavior using
	existing information carried in the association.		existing information carried in the association.
	6. The Usage of SCTP in the RTCWeb Context		6. The Usage of SCTP in the RTCWeb Context
	6.1. Association Setup		6.1. SCTP Protocol Considerations
			The DTLS encapsulation of SCTP packets as described in
			[I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. The following SCTP
			protocol extensions are required:
			o The stream reset extension defined in [RFC6525] MUST be supported.
			It is used for closing channels.
			o The dynamic address reconfiguration extension defined in [RFC5061]
			MUST be used to signal the support of the stream reset extension
			defined in [RFC6525], other features of [RFC5061] MUST NOT be
			used.
			o The partial reliability extension defined in [RFC3758] MUST be
			supported. In addition to the timed reliability PR-SCTP policy
			defined in [RFC3758], the limited retransmission policy defined in
			[I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported.
			o The message interleaving extension defined in
			[I-D.stewart-tsvwg-sctp-ndata] MUST be supported.
			6.2. Association Setup
	The SCTP association will be set up when the two endpoints of the		The SCTP association will be set up when the two endpoints of the
	WebRTC PeerConnection agree on opening it, as negotiated by JSEP		WebRTC PeerConnection agree on opening it, as negotiated by JSEP
	(typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally,		(typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally,
	the negotiation SHOULD include some type of congestion control		the negotiation SHOULD include some type of congestion control
	selection. It will use the DTLS connection selected via SDP;		selection. It will use the DTLS connection selected via SDP;
	typically this will be shared via BUNDLE or equivalent with DTLS		typically this will be shared via BUNDLE or equivalent with DTLS
	connections used to key the DTLS-SRTP media streams.		connections used to key the DTLS-SRTP media streams.
	The application SHOULD indicate the initial number of streams		The application SHOULD indicate the initial number of streams
	required when opening the association, and if no value is supplied,		required when opening the association, and if no value is supplied,
	the implementation SHOULD provide an appropriate default. If more		the implementation SHOULD provide an appropriate default. If more
	simultaneous streams are needed, [RFC6525] allows adding additional		simultaneous streams are needed, [RFC6525] allows adding additional
	(but not removing) streams to an existing association. Note there		(but not removing) streams to an existing association. Note there
	can be up to 65536 SCTP streams per SCTP association in each		can be up to 65536 SCTP streams per SCTP association in each
	direction.		direction.
	6.2. SCTP Streams		6.3. SCTP Streams
	SCTP defines a stream as an unidirectional logical channel existing		SCTP defines a stream as an unidirectional logical channel existing
	within an SCTP association one to another SCTP endpoint. The streams		within an SCTP association one to another SCTP endpoint. The streams
	are used to provide the notion of in-sequence delivery and for		are used to provide the notion of in-sequence delivery and for
	multiplexing. Each user message is sent on a particular stream,		multiplexing. Each user message is sent on a particular stream,
	either order or unordered. Ordering is preserved only for ordered		either order or unordered. Ordering is preserved only for ordered
	messages sent on the same stream.		messages sent on the same stream.
	6.3. Channel Definition		6.4. Channel Definition
	The W3C has consensus on defining the application API for WebRTC		The W3C has consensus on defining the application API for WebRTC
	dataChannels to be bidirectional. They also consider the notions of		dataChannels to be bidirectional. They also consider the notions of
	in-sequence, out-of-sequence, reliable and un-reliable as properties		in-sequence, out-of-sequence, reliable and un-reliable as properties
	of Channels. One strong wish is for the application-level API to be		of Channels. One strong wish is for the application-level API to be
	close to the API for WebSockets, which implies bidirectional streams		close to the API for WebSockets, which implies bidirectional streams
	of data and waiting for onopen to fire before sending, a textual		of data and waiting for onopen to fire before sending, a textual
	label used to identify the meaning of the stream, among other things.		label used to identify the meaning of the stream, among other things.
	The realization of a bidirectional Data Channel is a pair of one		The realization of a bidirectional Data Channel is a pair of one
	skipping to change at page 10, line 15		skipping to change at page 10, line 15
	Closing of a Data Channel MUST be signaled by resetting the		Closing of a Data Channel MUST be signaled by resetting the
	corresponding streams [RFC6525]. Resetting a stream set the Stream		corresponding streams [RFC6525]. Resetting a stream set the Stream
	Sequence Numbers (SSNs) of the stream back to 'zero' with a		Sequence Numbers (SSNs) of the stream back to 'zero' with a
	corresponding notification to the application layer that the reset		corresponding notification to the application layer that the reset
	has been performed. Streams are available to reuse after a reset has		has been performed. Streams are available to reuse after a reset has
	been performed.		been performed.
	[RFC6525] also guarantees that all the messages are delivered (or		[RFC6525] also guarantees that all the messages are delivered (or
	expired) before resetting the stream.		expired) before resetting the stream.
	6.4. Usage of Payload Protocol Identifier		6.5. Usage of Payload Protocol Identifier
	The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal		The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal
	the interpretation of the "Payload data", like the protocol specified		the interpretation of the "Payload data", like the protocol specified
	in [I-D.jesup-rtcweb-data-protocol] uses them to identify a		in [I-D.jesup-rtcweb-data-protocol] uses them to identify a
	Javascript string, a Javascript binary data (ArrayBuffer or Blob) and		Javascript string, a Javascript binary data (ArrayBuffer or Blob) and
	to provide fragmentation support for large messages that may cause		to provide fragmentation support for large messages that may cause
	the message to monopolize the SCTP association.		the message to monopolize the SCTP association.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 11, line 13		skipping to change at page 11, line 12
	Conrad, "Stream Control Transmission Protocol (SCTP)		Conrad, "Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension", RFC 3758, May 2004.		Partial Reliability Extension", RFC 3758, May 2004.
	[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and		[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
	Parameter for the Stream Control Transmission Protocol		Parameter for the Stream Control Transmission Protocol
	(SCTP)", RFC 4820, March 2007.		(SCTP)", RFC 4820, March 2007.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
	RFC 4960, September 2007.		4960, September 2007.
			[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
			Kozuka, "Stream Control Transmission Protocol (SCTP)
			Dynamic Address Reconfiguration", RFC 5061, September
			2007.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245,		Traversal for Offer/Answer Protocols", RFC 5245, April
	April 2010.		2010.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
	[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control		[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
	Transmission Protocol (SCTP) Stream Reconfiguration",		Transmission Protocol (SCTP) Stream Reconfiguration", RFC
	RFC 6525, February 2012.		6525, February 2012.
			[I-D.stewart-tsvwg-sctp-ndata]
			Stewart, R., Tuexen, M., and S. Loreto, "A New Data Chunk
			for Stream Control Transmission Protocol", draft-stewart-
			tsvwg-sctp-ndata-01 (work in progress), February 2013.
	[I-D.jesup-rtcweb-data-protocol]		[I-D.jesup-rtcweb-data-protocol]
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel		Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
	Protocol", draft-jesup-rtcweb-data-protocol-03 (work in		Protocol", draft-jesup-rtcweb-data-protocol-04 (work in
	progress), September 2012.		progress), February 2013.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[I-D.ietf-tsvwg-sctp-dtls-encaps]
	Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS		Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS
	Encapsulation of SCTP Packets for RTCWEB",		Encapsulation of SCTP Packets for RTCWEB", draft-ietf-
	draft-ietf-tsvwg-sctp-dtls-encaps-00 (work in progress),		tsvwg-sctp-dtls-encaps-00 (work in progress), February
	February 2013.		2013.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for RTC-Web",		Rescorla, E., "Security Considerations for RTC-Web",
	draft-ietf-rtcweb-security-04 (work in progress),		draft-ietf-rtcweb-security-04 (work in progress), January
	January 2013.		2013.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "RTCWEB Security Architecture",		Rescorla, E., "RTCWEB Security Architecture", draft-ietf-
	draft-ietf-rtcweb-security-arch-06 (work in progress),		rtcweb-security-arch-06 (work in progress), January 2013.
	January 2013.
	[I-D.ietf-rtcweb-jsep]		[I-D.ietf-rtcweb-jsep]
	Uberti, J. and C. Jennings, "Javascript Session		Uberti, J. and C. Jennings, "Javascript Session
	Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work		Establishment Protocol", draft-ietf-rtcweb-jsep-03 (work
	in progress), October 2012.		in progress), February 2013.
	[I-D.ietf-rtcweb-qos]		[I-D.ietf-rtcweb-qos]
	Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and		Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and
	other packet markings for RTCWeb QoS",		other packet markings for RTCWeb QoS", draft-ietf-rtcweb-
	draft-ietf-rtcweb-qos-00 (work in progress), October 2012.		qos-00 (work in progress), October 2012.
	10.2. Informative References		10.2. Informative References
	[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram		[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
	Transport Layer Security (DTLS) for Stream Control		Transport Layer Security (DTLS) for Stream Control
	Transmission Protocol (SCTP)", RFC 6083, January 2011.		Transmission Protocol (SCTP)", RFC 6083, January 2011.
			[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
			Control Transmission Protocol (SCTP) Packets for End-Host
			to End-Host Communication", RFC 6951, May 2013.
	[I-D.ietf-rtcweb-use-cases-and-requirements]		[I-D.ietf-rtcweb-use-cases-and-requirements]
	Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Time Communication Use-cases and Requirements",		Time Communication Use-cases and Requirements", draft-
	draft-ietf-rtcweb-use-cases-and-requirements-10 (work in		ietf-rtcweb-use-cases-and-requirements-11 (work in
	progress), December 2012.		progress), June 2013.
	[I-D.ietf-tsvwg-sctp-udp-encaps]		[I-D.tuexen-tsvwg-sctp-prpolicies]
	Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP		Loreto, S., Seggelmann, R., Stewart, R., and M. Tuexen,
	Packets for End-Host to End-Host Communication",		"Additional Policies for the Partial Delivery Extension of
	draft-ietf-tsvwg-sctp-udp-encaps-11 (work in progress),		the Stream Control Transmission Protocol", draft-tuexen-
	February 2013.		tsvwg-sctp-prpolicies-02 (work in progress), July 2013.
	Authors' Addresses		Authors' Addresses
	Randell Jesup		Randell Jesup
	Mozilla		Mozilla
	US		US
	Email: randell-ietf@jesup.org		Email: randell-ietf@jesup.org
	Salvatore Loreto		Salvatore Loreto
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	FI		FI
	Email: salvatore.loreto@ericsson.com		Email: salvatore.loreto@ericsson.com
	Michael Tuexen		Michael Tuexen
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	Steinfurt 48565		Steinfurt 48565
	DE		DE
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
End of changes. 45 change blocks.
	128 lines changed or deleted		160 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/