One document matched: draft-holmberg-clue-datachannel-02.xml

<?xml version="1.0" encoding="iso-8859-1"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">

]>




<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>

<rfc ipr="trust200902" category="std" docName="draft-holmberg-clue-datachannel-02" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
	<front>
		<title abbrev="CLUE Protocol Data Channel">
			CLUE Protocol Data Channel
		</title>
    		<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
			<organization>Ericsson</organization>
			<address>
				<postal>
					<street>Hirsalantie 11</street>
					<code>02420</code>
					<city>Jorvas</city>
					<country>Finland</country>
				</postal>
				<email>christer.holmberg@ericsson.com</email>
			</address>
		</author>

		<date year="2014" />
		<area>Transport</area>
		<workgroup>CLUE Working Group</workgroup>
		<keyword>SIP</keyword>
		<keyword>SDP</keyword>
		<keyword>DTLS</keyword>
		<keyword>SCTP</keyword>
		<keyword>DATA</keyword>
		<keyword>CHANNEL</keyword>
		<keyword>PPID</keyword>
		<keyword>TELEPRESENCE</keyword>
		<keyword>RTCWEB</keyword>
		<keyword>WEBRTC</keyword>
		<abstract>
			<t>
				This document specifies how to use the Stream Control
				Transmission Protocol (SCTP) on top of the Datagram Transport Layer
				Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol
				messages between CLUE entities.
			</t>
			<t>
				The document describes the SCTP considerations for CLUE, and
				the SDP Offer/Answer procedures for negotiating a SCTPoDTLS
				connection for CLUE.
			</t>
			<t>
				Details and procedures associated with the CLUE protocol are 
				outside the scope of this document.
			</t>
		</abstract>
	</front>
	
	<middle>
		<section title="Introduction" toc="default">
			<t>
				This document specifies how to use the Stream Control
				Transmission Protocol (SCTP) on top of the Datagram Transport Layer
				Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol
				messages between CLUE entities.
			</t>
			<t>
				The document describes the SCTP considerations for CLUE, and
				the SDP Offer/Answer procedures for negotiating a SCTPoDTLS
				connection for CLUE.
			</t>
			<t>
				Details and procedures associated with the CLUE protocol are 
				outside the scope of this document.
			</t>
		</section>
		<section title="Conventions" toc="default">
			<t>
				The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
				"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted 
				as described in BCP 14, RFC 2119 <xref target="RFC2119" pageno="false" format="default" />.
			</t>
			<t>
				CLUE data channel refers to the SCTPoDTLS association that is used between two
				CLUE entities in order to transport CLUE messages.
			</t>
			<t>
				CLUE message refers to a CLUE protocol message that is sent over the CLUE data channel.
			</t>
			<t>
				CLUE entity refers to a SIP User Agent (UA) device that supports the CLUE
				mechanism (including the CLUE protocol).
			</t>
			<t>
				<xref target="RFC4960" pageno="false" format="default" /> defines a SCTP stream as a 
				unidirectional logical channel established from one to another associated SCTP endpoint, 
				within which all user messages are delivered in sequence except for those submitted to the
				unordered delivery service.
			</t>
			<t>
				<xref target="RFC4960" pageno="false" format="default" /> defines a SCTP identifier as a 
				unsigned integer, which identifies an SCTP stream.
			</t>
		</section>

		<section anchor="section.dtls" title="Usage of SCTPoDTLS in the CLUE Context" toc="default">
			<section anchor="section.dtls.gen" title="General" toc="default">
				<t>
					This section defines the CLUE data channel, and describes the SCTP features
					and extensions used to realize it.
				</t>
				<t>
					The CLUE data channel realization, and set of SCTP features, are based on the 
					the RTCWEB data channel defined in <xref target="I-D.ietf-rtcweb-data-channel" 
					pageno="false" format="default" />. This will allow CLUE entities to be interoperable
					with entities implementing <xref target="I-D.ietf-rtcweb-data-channel" 
					pageno="false" format="default" />.
				</t>					
			</section>
			<section anchor="section.dtls.channel" title="CLUE Data Channel Definition" toc="default">
				<t>
					The CLUE data channel is realized by using the Stream Control 
					Transmission Protocol (SCTP) on top of the Datagram Transport 
					Layer Security (DTLS) protocol <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps" 
					pageno="false" format="default" />.
				</t>
				<t>
					The realization of a bidirectional CLUE Data Channel is a pair of one
					incoming SCTP stream and one outgoing SCTP stream. These streams are 
					then used to transport CLUE messages in both directions.
				</t>
				<t>
					The SCTP streams MUST belong to the same SCTP association.					
				</t>
				<t>
					Within a given CLUE session, CLUE entities MUST use a single CLUE
					data channel for all CLUE messages associated with the CLUE session.				
				</t>
				<t>
					The SCTP streams MUST have identical SCTP stream identifier values,
					unless a specific value is already used for some other purpose.
				</t>				
				<t>
					OPEN ISSUE #1: The requirement to use identical STCP stream identifier values
					might be modified depending on what mechanism will be used to negotiate
					the identifier values.
				</t>
			</section>
			<section anchor="section.dtls.dcp" title="RTCWEB Data Channel Protocol Usage" toc="default">
				<t>
					OPEN ISSUE #2: It is FFS whether the RTCWEB Data Channel Protocol
					<xref target="I-D.ietf-rtcweb-data-protocol" pageno="false" format="default" /> 
					will be used with the CLUE data channel.
				</t>
				<t>
					NOTE: If <xref target="I-D.ietf-rtcweb-data-protocol" pageno="false" format="default" />
					will be used with the CLUE data channel, a new associated 'protocol' value needs to be registered
					with IANA in the 'Protocol Registry' defined by <xref target="I-D.ietf-rtcweb-data-protocol" pageno="false" 
					format="default" />.
				</t>
			</section>
			<section anchor="section.dtls.sctp" title="SCTP Considerations" toc="default">
				<section anchor="section.dtls.sctp.ppid" title="SCTP Payload Protocol Identifier (PPID)" toc="default">
					<t>
						CLUE entities MUST use the PPID value XX, according to the 
						procedures in <xref target="I-D.ietf-rtcweb-data-channel" 
						pageno="false" format="default" />.
					</t>
					<t>
						NOTE: As described in <xref target="I-D.ietf-rtcweb-data-channel" 
						pageno="false" format="default" />, the PPID value XX indicates
						that the SCTP message contains data encoded in a UTF-8 format 
						[reference-needed]. The PPID value XX does not indicate what
						protocol the SCTP message contains.
					</t>
					<t>
						NOTE: If the RTCWEB Data Channel Protocol <xref target="I-D.ietf-rtcweb-data-protocol" 
						pageno="false" format="default" />  will be used for the CLUE data channel, the PPID 
						value 50 will be used for Data Channel Protocol messages.
					</t>
				</section>
				<section anchor="section.dtls.sctp.reliability" title="Reliability" toc="default">
					<t>
						The usage of SCTP for the data channel ensures reliable transport of CLUE messages.						
					</t>
					<t>
						NOTE: <xref target="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />
						requires the support of the partial reliability extension defined in
						<xref target="RFC3758" pageno="false" format="default" />. This is not needed for CLUE,
						as messages are required to always be sent reliably. <xref target="I-D.ietf-rtcweb-data-channel" 
						pageno="false" format="default" /> also mandates support of the limited 
						retransmission policy defined in <xref target="I-D.tuexen-tsvwg-sctp-prpolicies" 
						pageno="false" format="default" />.
					</t>
				</section>
				<section anchor="section.dtls.sctp.order" title="Order" toc="default">
					<t>
						CLUE entities MUST use the ordered delivery SCTP service, as described in section 6.6 of
						<xref target="RFC2960" pageno="false" format="default" />.
					</t>
				</section>
				<section anchor="section.dtls.sctp.streamreset" title="Stream Reset" toc="default">
					<t>
						CLUE entities MUST support the stream reset extension defined in <xref target="RFC6525" 
						pageno="false" format="default" />
					</t>
					<t>The dynamic address reconfiguration extension defined in <xref target="RFC5061" 
						pageno="false" format="default" /> MUST be used to signal the support of the stream 
						reset extension defined in <xref target="RFC6525" pageno="false" format="default" />. 
						Other features of <xref target="RFC5061" pageno="false" format="default" /> MUST NOT 
						be used.
					</t>
				</section>
				<section anchor="section.dtls.sctp.interleaving" title="Interleaving" toc="default">
					<t>
						CLUE entities MUST support the message interleaving mechanism 
						defined in <xref target="I-D.stewart-tsvwg-sctp-ndata" pageno="false" 
						format="default" />.
					</t>
				</section>				
				<section anchor="section.dtls.sctp.multihome" title="SCTP Multihoming" toc="default">
					<t>
						CLUE entities MUST NOT use SCTP multihoming.
					</t>
					<t>
						NOTE: The SCTPoDTLS mechanism does not support SCTP multihoming.
					</t>
				</section>
			</section>
		</section>

		<section anchor="section.oa" title="SDP Offer/Answer Procedures" toc="default">
			<section anchor="section.oa.sdp.neg" title="SDP-based WebRTC Data Channel Negotiation Usage" toc="default">
				<t>
					OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel Negotiation mechanism
					<xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg" pageno="false" format="default" /> 
					will be used with the CLUE data channel.
				</t>
				<t>
					NOTE: If <xref target="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg" pageno="false" format="default" />
					will be used with the CLUE data channel, a new associated 'sub-protocol' value needs to be registered
					with IANA.				
				</t>
			</section>
		</section>


		<section anchor="section.sec" title="Security Considerations">
			<t>
				TBD
			</t>
		</section>
		<section anchor="section.iana" title="IANA Considerations">
			<t>
				[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.]
			</t>
		</section>
		<section title="Acknowledgments">
			<t>
				Thanks to Paul Kyzivat and Christian Groves for comments on the document.
			</t>
		</section>
		<section title="Change Log">
			<t>
				[RFC EDITOR NOTE: Please remove this section when publishing]
			</t>
			<t>
				Changes from draft-holmberg-clue-datachannel-01
				<list style="symbols">
					<t>More text added</t>
				</list>
			</t>			
			<t>
				Changes from draft-holmberg-clue-datachannel-00
				<list style="symbols">
					<t>Editorial corrections based on comments from Paul K</t>
				</list>
			</t>			
		</section>
	</middle>
	<back>
		<references title="Normative References">
			<?rfc include="reference.RFC.2119"?>
			<?rfc include="reference.RFC.2960"?>
			<?rfc include="reference.RFC.3261"?>
			<?rfc include="reference.RFC.3264"?>
			<?rfc include="reference.RFC.4960"?>
			<?rfc include="reference.RFC.5061"?>
			<?rfc include="reference.RFC.6525"?>
			<reference anchor="I-D.ietf-tsvwg-sctp-dtls-encaps">
				<front>
					<title abbrev="SCTP over DLTS">
						DTLS Encapsulation of SCTP Packets
					</title>
					<author fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization>
					</author>
					<author fullname="Randall Stewart" initials="R.S" surname="Stewart">
						<organization>Adara Networks</organization>
					</author>
					<author fullname="Randell Jesup" initials="R.J" surname="Jesup">
						<organization>WorldGate Communications</organization>
					</author>
					<author fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization>
					</author>				
					<date day="20" month="October" year="2013" />
				</front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-sctp-dtls-encaps-02.txt" />
			</reference>		
			<reference anchor="I-D.ietf-rtcweb-data-channel">
				<front>
					<title abbrev="RTCWeb Data Channels">
						RTCWeb Data Channels
					</title>
					<author fullname="Randell Jesup" initials="R.J" surname="Jesup">
						<organization>WorldGate Communications</organization>
					</author>
					<author fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization>
					</author>
					<author fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization>
					</author>				
					<date day="21" month="October" year="2013" />
				</front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-channel-06.txt" />
			</reference>					
			<reference anchor="I-D.ietf-rtcweb-data-protocol">
				<front>
					<title abbrev="RTCWeb Data Channel Protocol">
						RTCWeb Data Channel Protocol
					</title>
					<author fullname="Randell Jesup" initials="R.J" surname="Jesup">
						<organization>WorldGate Communications</organization>
					</author>
					<author fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization>
					</author>
					<author fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization>
					</author>				
					<date day="21" month="October" year="2013" />
				</front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-protocol-01.txt" />
			</reference>	
			<reference anchor="I-D.ejzak-dispatch-webrtc-data-channel-sdpneg">
				<front>
					<title abbrev="SDP-based WebRTC data channel negotiation">
						SDP-based WebRTC data channel negotiation
					</title>
					<author fullname="Richard Ejzak" initials="R.E" surname="Ejzak">
						<organization>Alcatel-Lucent</organization>
					</author>
					<author fullname="Jerome Marcon" initials="J.M" surname="Marcon">
						<organization>Alcatel-Lucent</organization>
					</author>
					<date day="14" month="October" year="2013" />
				</front>
				<seriesInfo name="Internet-Draft" value="draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt" />
			</reference>					
			<reference anchor="I-D.stewart-tsvwg-sctp-ndata">
				<front>
					<title abbrev="SCTP N-DATA Chunk">
						A New Data Chunk for Stream Control Transmission Protocol
					</title>
					<author fullname="Randall Stewart" initials="R.S" surname="Stewart">
						<organization>Adara Networks</organization>
					</author>
					<author fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization>
					</author>				
					<author fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization>
					</author>

					<author fullname="Robin Seggelmann" initials="R.S" surname="Seggelmann">
						<organization>T-Systems International GmbH</organization>
					</author>
					<date day="20" month="October" year="2013" />
				</front>
				<seriesInfo name="Internet-Draft" value="draft-stewart-tsvwg-sctp-ndata-03.txt" />
			</reference>					
			<reference anchor="I-D.tuexen-tsvwg-sctp-prpolicies">
				<front>
					<title abbrev="Additional PR-SCTP Policies">
						Additional Policies for the Partial Delivery Extension of the Stream
						Control Transmission Protocol
					</title>
					<author fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization>
					</author>		
					<author fullname="Robin Seggelmann" initials="R.S" surname="Seggelmann">
						<organization>T-Systems International GmbH</organization>
					</author>					
					<author fullname="Randall Stewart" initials="R.S" surname="Stewart">
						<organization>Adara Networks</organization>
					</author>
					<author fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization>
					</author>
					<date day="20" month="October" year="2013" />
				</front>
				<seriesInfo name="Internet-Draft" value="draft-tuexen-tsvwg-sctp-prpolicies-03.txt" />
			</reference>					
		</references>
		<references title="Informative References">
			<?rfc include="reference.RFC.3758"?>
		</references>
	</back>
</rfc>