draft-ietf-rtcweb-data-channel-11.txt   draft-ietf-rtcweb-data-channel-12.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: January 5, 2015 Ericsson Expires: April 1, 2015 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
July 4, 2014 September 28, 2014
WebRTC Data Channels WebRTC Data Channels
draft-ietf-rtcweb-data-channel-11.txt draft-ietf-rtcweb-data-channel-12.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 the non-media data two peers' web-browsers. This document specifies the non-media data
transport aspects of the WebRTC framework. It provides an transport aspects of the WebRTC framework. It provides an
architectural overview of how the Stream Control Transmission architectural overview of how the Stream Control Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport Protocol (SCTP) is used in the WebRTC context as a generic transport
service allowing WEB-browsers to exchange generic data from peer to service allowing WEB-browsers to exchange generic data from peer to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 5, 2015. This Internet-Draft will expire on April 1, 2015.
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 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . 3 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 . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5
6. The Usage of SCTP for Data Channels . . . . . . . . . . . . . 8 6. The Usage of SCTP for Data Channels . . . . . . . . . . . . . 8
6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8 6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8
6.2. Association Setup . . . . . . . . . . . . . . . . . . . . 9 6.2. SCTP Association Management . . . . . . . . . . . . . . . 9
6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9 6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9
6.4. WebRTC Data Channel Definition . . . . . . . . . . . . . 9 6.4. Data Channel Definition . . . . . . . . . . . . . . . . . 9
6.5. Opening a Channel . . . . . . . . . . . . . . . . . . . . 10 6.5. Opening a Data Channel . . . . . . . . . . . . . . . . . 10
6.6. Transferring User Data on a Channel . . . . . . . . . . . 10 6.6. Transferring User Data on a Data Channel . . . . . . . . 11
6.7. Closing a Channel . . . . . . . . . . . . . . . . . . . . 11 6.7. Closing a Data Channel . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In the WebRTC framework, communication between the parties consists In the WebRTC framework, communication between the parties consists
of media (for example audio and video) and non-media data. Media is of media (for example audio and video) and non-media data. Media is
sent using SRTP, and is not specified further here. Non-media data sent using SRTP, and is not specified further here. Non-media data
is handled by using SCTP [RFC4960] encapsulated in DTLS [RFC4347]. is handled by using SCTP [RFC4960] encapsulated in DTLS [RFC4347].
+----------+ +----------+
| SCTP | | SCTP |
skipping to change at page 7, line 13 skipping to change at page 7, line 13
Figure 2. Figure 2.
+------+------+------+ +------+------+------+
| DCEP | UTF-8|Binary| | DCEP | UTF-8|Binary|
| | data | data | | | data | data |
+------+------+------+ +------+------+------+
| SCTP | | SCTP |
+----------------------------------+ +----------------------------------+
| STUN | SRTP | DTLS | | STUN | SRTP | DTLS |
+----------------------------------+ +----------------------------------+
| ICE | | ICE |
+----------------------------------+ +----------------------------------+
| UDP1 | UDP2 | ... | | UDP1 | UDP2 | UDP3 | ... |
+----------------------------------+ +----------------------------------+
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 [RFC6951]) has been chosen because it combination with SCTP over UDP [RFC6951]) has 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 SRTP media channels of the o shares the DTLS connection with the SRTP media channels of the
skipping to change at page 8, line 22 skipping to change at page 8, line 22
complete SCTP packet, so it provides confidentiality, integrity and complete SCTP packet, so it provides confidentiality, integrity and
source authentication of the complete SCTP packet. source authentication of the complete SCTP packet.
SCTP provides congestion control on a per-association base. This SCTP provides congestion control on a per-association base. This
means that all SCTP streams within a single SCTP association share means that all SCTP streams within a single SCTP association share
the same congestion window. Traffic not being sent over SCTP is not the same congestion window. Traffic not being sent over SCTP is not
covered by the SCTP congestion control. Using a congestion control covered by the SCTP congestion control. Using a congestion control
different from than the standard one might improve the impact on the different from than the standard one might improve the impact on the
parallel SRTP media streams. parallel SRTP media streams.
SCTP uses the same port number concept as TCP and UDP do. Therefore
an SCTP association uses two port numbers, one at each SCTP end-
point.
6. The Usage of SCTP for Data Channels 6. The Usage of SCTP for Data Channels
6.1. SCTP Protocol Considerations 6.1. SCTP Protocol Considerations
The DTLS encapsulation of SCTP packets as described in The DTLS encapsulation of SCTP packets as described in
[I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used.
This SCTP stack and its upper layer MUST support the usage of This SCTP stack and its upper layer MUST support the usage of
multiple SCTP streams. A user message can be sent ordered or multiple SCTP streams. A user message can be sent ordered or
unordered and with partial or full reliability. unordered and with partial or full reliability.
skipping to change at page 9, line 8 skipping to change at page 9, line 10
supported. In addition to the timed reliability PR-SCTP policy supported. In addition to the timed reliability PR-SCTP policy
defined in [RFC3758], the limited retransmission policy defined in defined in [RFC3758], the limited retransmission policy defined in
[I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the
number of retransmissions to zero combined with unordered delivery number of retransmissions to zero combined with unordered delivery
provides a UDP-like service where each user message is sent provides a UDP-like service where each user message is sent
exactly once and delivered in the order received. exactly once and delivered in the order received.
The support for message interleaving as defined in The support for message interleaving as defined in
[I-D.ietf-tsvwg-sctp-ndata] SHOULD be used. [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used.
6.2. Association Setup 6.2. SCTP Association Management
In the WebRTC context, the SCTP association will be set up when the In the WebRTC context, the SCTP association will be set up when the
two endpoints of the WebRTC PeerConnection agree on opening it, as two endpoints of the WebRTC PeerConnection agree on opening it, as
negotiated by JSEP (typically an exchange of SDP) negotiated by JSEP (typically an exchange of SDP)
[I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via [I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via
ICE; typically this will be shared via BUNDLE or equivalent with DTLS ICE; typically this will be shared via BUNDLE or equivalent with DTLS
connections used to key the SRTP media streams. connections used to key the SRTP media streams.
The number of streams negotiated during SCTP association setup SHOULD The number of streams negotiated during SCTP association setup SHOULD
be 65535, which is the maximum number of streams that can be be 65535, which is the maximum number of streams that can be
negotiated during the association setup. negotiated during the association setup.
SCTP supports two ways of terminating an SCTP association. A
graceful one, using a procedure which ensures that no messages are
lost during the shutdown of the association. The second method is a
non-graceful one, where one side can just abort the association.
Each SCTP end-point supervises continuously the reachability of its
peer by monitoring the number of retransmissions of user messages and
test messages. In case of excessive retransmissions, the association
is terminated in a non-graceful way.
If an SCTP association is closed in a graceful way, all of its data
channels are closed. In case of a non-graceful teardown, all data
channels are also closed, but an error indication SHOULD be provided
if possible.
6.3. SCTP Streams 6.3. SCTP Streams
SCTP defines a stream as a unidirectional logical channel existing SCTP defines a stream as a unidirectional logical channel existing
within an SCTP association to another SCTP endpoint. The streams are within an SCTP association to another SCTP endpoint. The streams are
used to provide the notion of in-sequence delivery and for 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 ordered or unordered. Ordering is preserved only for ordered either ordered or unordered. Ordering is preserved only for ordered
messages sent on the same stream. messages sent on the same stream.
6.4. WebRTC Data Channel Definition 6.4. Data Channel Definition
The WebRTC Data Channels are bidirectional. They also consider the One strong wish is for the application-level API to be close to the
notions of in-sequence, out-of-sequence, reliable and unreliable as API for WebSockets, which implies bidirectional streams of data and a
properties of channels. One strong wish is for the application-level textual field called 'label' used to identify the meaning of the data
API to be close to the API for WebSockets, which implies channel.
bidirectional streams of data and waiting for onopen to fire before
sending, a textual label used to identify the meaning of the streams.
The realization of a bidirectional data channel is a pair of one The realization of a data channel is a pair of one incoming stream
incoming stream and one outgoing SCTP stream having the same stream and one outgoing SCTP stream having the same SCTP stream identifier.
SCTP identifier. How these SCTP stream identifiers are selected is protocol and
implementation dependent. This allows a bidirectional communication.
How stream values are selected is protocol and implementation Additionally, each data channel has the following properties in each
dependent. direction:
Each data channel also has a priority, which is an 2 byte unsigned o reliable or unreliable message transmission. In case of
integer value. These priorities MUST be interpreted as weighted- unreliable transmissions, the same level of unreliability is used.
fair-queuing scheduling priorities per the definition of the Please note that in SCTP this is a property of an SCTP user
corresponding stream scheduler supporting interleaving in message and not of an SCTP stream.
[I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used
SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high")
or 1024 ("extra high").
6.5. Opening a Channel o in-order or out-of-order message delivery for message sent.
Please note that in SCTP this is a property of an SCTP user
message and not of an SCTP stream.
o A priority, which is a 2 byte unsigned integer. These priorities
MUST be interpreted as weighted-fair-queuing scheduling priorities
per the definition of the corresponding stream scheduler
supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use
in WebRTC, the values used SHOULD be one of 128 ("below normal"),
256 ("normal"), 512 ("high") or 1024 ("extra high").
o an optional label.
o an optional protocol.
Please note that for a data channel being negotiated with the
protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the
above properties are the same in both directions.
6.5. Opening a Data Channel
Data channels can be opened by using negotiation within the SCTP Data channels can be opened by using negotiation within the SCTP
association, called in-band negotiation, or out-of-band negotiation. association, called in-band negotiation, or out-of-band negotiation.
Out-of-band negotiation is defined as any method which results in an Out-of-band negotiation is defined as any method which results in an
agreement as to the parameters of a channel and the creation thereof. agreement as to the parameters of a channel and the creation thereof.
The details are out of scope of this document. The details are out of scope of this document. Applications using
data channels need to use the negotiation methods consistently on
both end-points.
A simple protocol for in-band negotiation is specified in A simple protocol for in-band negotiation is specified in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
When one side wants to open a channel using out-of-band negotiation, When one side wants to open a channel using out-of-band negotiation,
it picks a stream. Unless otherwise defined or negotiated, the it picks a stream. Unless otherwise defined or negotiated, the
streams are picked based on the DTLS role (the client picks even streams are picked based on the DTLS role (the client picks even
stream identifiers, the server odd stream identifiers). However, the stream identifiers, the server odd stream identifiers). However, the
application is responsible for avoiding collisions with existing application is responsible for avoiding collisions with existing
streams. If it attempts to re-use a stream which is part of an streams. If it attempts to re-use a stream which is part of an
existing data channel, the addition SHOULD fail. In addition to existing data channel, the addition SHOULD fail. In addition to
choosing a stream, the application SHOULD also determine the options choosing a stream, the application SHOULD also determine the options
to use for sending messages. The application MUST ensure in an to use for sending messages. The application MUST ensure in an
application-specific manner that the application at the peer will application-specific manner that the application at the peer will
also know the selected stream to be used, and the options for sending also know the selected stream to be used, and the options for sending
data from that side. data from that side.
6.6. Transferring User Data on a Channel 6.6. Transferring User Data on a Data Channel
All data sent on a data channel in both directions MUST be sent over All data sent on a data channel in both directions MUST be sent over
the underlying stream using the reliability defined when the data the underlying stream using the reliability defined when the data
channel was opened unless the options are changed, or per-message channel was opened unless the options are changed, or per-message
options are specified by a higher level. options are specified by a higher level.
No more than one message should be put into an SCTP user message. No more than one message should be put into an SCTP user message.
The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
interpretation of the "Payload data". For identifying a JavaScript interpretation of the "Payload data". The following PPIDs MUST be
string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for used (see Section 8):
JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary"
MUST be used (see Section 8). WebRTC String: to identify a non-empty JavaScript string encoded in
UTF-8.
WebRTC String Empty: to identify an empty JavaScript string encoded
in UTF-8.
WebRTC Binary: to identify a non-empty JavaScript binary data
(ArrayBuffer, ArrayBufferView or Blob).
WebRTC Binary Empty: to identify an empty JavaScript binary data
(ArrayBuffer, ArrayBufferView or Blob).
SCTP does not support the sending of empty user messages. Therefore,
if an empty message has to be sent, the appropriate PPID (WebRTC
String Empty or WebRTC Binary Empty) is used and the SCTP user
message of one zero byte is sent. When receiving an SCTP user
message with one of these PPIDs, the receiver MUST ignore the SCTP
user message and process it as an empty message.
The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary
Partial" is deprecated. They were used for a PPID-based Partial" is deprecated. They were used for a PPID-based
fragmentation and reassembly of user messages belonging to reliable fragmentation and reassembly of user messages belonging to reliable
and ordered data channels. and ordered data channels.
If a message with an unsupported PPID is received or some error is If a message with an unsupported PPID is received or some error
detected by the receiver (for example, illegal ordering), the condition related to the received message is detected by the receiver
receiver SHOULD close the corresponding data channel. (for example, illegal ordering), the receiver SHOULD close the
corresponding data channel. This implies in particular that
extensions using additional PPIDs can't be used without prior
negotiation.
The SCTP base protocol specified in [RFC4960] does not support the The SCTP base protocol specified in [RFC4960] does not support the
interleaving of user messages. Therefore sending a large user interleaving of user messages. Therefore sending a large user
message can monopolize the SCTP association. To overcome this message can monopolize the SCTP association. To overcome this
limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to
support message interleaving, which SHOULD be used. As long as support message interleaving, which SHOULD be used. As long as
message interleaving is not supported, the sender SHOULD limit the message interleaving is not supported, the sender SHOULD limit the
maximum message size to 16 KB to avoid monopolization. maximum message size to 16 KB to avoid monopolization.
It is recommended that the message size be kept within certain size It is recommended that the message size be kept within certain size
bounds as applications will not be able to support arbitrarily-large bounds as applications will not be able to support arbitrarily-large
single messages. This limit has to be negotiated, for example by single messages. This limit has to be negotiated, for example by
using [I-D.ietf-mmusic-sctp-sdp]. using [I-D.ietf-mmusic-sctp-sdp].
The sender SHOULD disable the Nagle algorithm to minimize the The sender SHOULD disable the Nagle algorithm (see [RFC1122]) to
latency. minimize the latency.
6.7. Closing a Channel 6.7. Closing a Data Channel
Closing of a data channel MUST be signaled by resetting the Closing of a data channel MUST be signaled by resetting the
corresponding outgoing streams [RFC6525]. This means that if one corresponding outgoing streams [RFC6525]. This means that if one
side decides to close the data channel, it resets the corresponding side decides to close the data channel, it resets the corresponding
outgoing stream. When the peer sees that an incoming stream was outgoing stream. When the peer sees that an incoming stream was
reset, it also resets its corresponding outgoing stream. Once this reset, it also resets its corresponding outgoing stream. Once this
is completed, the data channel is closed. Resetting a stream sets is completed, the data channel is closed. Resetting a stream sets
the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with
a corresponding notification to the application layer that the reset a corresponding notification to the application layer that the reset
has been performed. Streams are available for reuse after a reset has been performed. Streams are available for reuse after a reset
skipping to change at page 12, line 7 skipping to change at page 13, line 17
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.
] ]
This document uses four already registered SCTP Payload Protocol This document uses six already registered SCTP Payload Protocol
Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary
Data Last", and "DOMString Partial". [RFC4960] creates the registry Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC
"SCTP Payload Protocol Identifiers" from which these identifiers were Binary Empty". [RFC4960] creates the registry "SCTP Payload Protocol
assigned. IANA is requested to update the reference of these four Identifiers" from which these identifiers were assigned. IANA is
assignments to point to this document and change the names of the requested to update the reference of these six assignments to point
PPIDs. Therefore these four assignments should be updated to read: to this document and change the names of the first four PPIDs. The
corresponding dates should be kept.
+------------------------------------+-----------+-----------+ Therefore these six assignments should be updated to read:
| Value | SCTP PPID | Reference |
+------------------------------------+-----------+-----------+ +-------------------------------+----------+-----------+------------+
| WebRTC String | 51 | [RFCXXXX] | | Value | SCTP | Reference | Date |
| WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] | | | PPID | | |
| WebRTC Binary | 53 | [RFCXXXX] | +-------------------------------+----------+-----------+------------+
| WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] | | WebRTC String | 51 | [RFCXXXX] | 2013-09-20 |
+------------------------------------+-----------+-----------+ | WebRTC Binary Partial | 52 | [RFCXXXX] | 2013-09-20 |
| (Deprecated) | | | |
| WebRTC Binary | 53 | [RFCXXXX] | 2013-09-20 |
| WebRTC String Partial | 54 | [RFCXXXX] | 2013-09-20 |
| (Deprecated) | | | |
| WebRTC String Empty | 56 | [RFCXXXX] | 2014-08-22 |
| WebRTC Binary Empty | 57 | [RFCXXXX] | 2014-08-22 |
+-------------------------------+----------+-----------+------------+
9. Acknowledgments 9. Acknowledgments
Many thanks for comments, ideas, and text from Harald Alvestrand, Many thanks for comments, ideas, and text from Harald Alvestrand,
Adam Bergkvist, Christer Holmberg, Cullen Jennings, Paul Kyzivat, Richard Barnes, Adam Bergkvist, Gunnar Hellstrom, Christer Holmberg,
Eric Rescorla, Irene Ruengeler, Randall Stewart, Justin Uberti, and Cullen Jennings, Paul Kyzivat, Eric Rescorla, Irene Ruengeler,
Magnus Westerlund. Randall Stewart, Justin Uberti, and Magnus Westerlund.
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.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
skipping to change at page 13, line 23 skipping to change at page 14, line 44
[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, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[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", RFC Transmission Protocol (SCTP) Stream Reconfiguration", RFC
6525, February 2012. 6525, February 2012.
[I-D.ietf-tsvwg-sctp-ndata] [I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
New Data Chunk for Stream Control Transmission Protocol", "Stream Schedulers and a New Data Chunk for the Stream
draft-ietf-tsvwg-sctp-ndata-00 (work in progress), Control Transmission Protocol", draft-ietf-tsvwg-sctp-
February 2014. ndata-01 (work in progress), July 2014.
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data- Establishment Protocol", draft-ietf-rtcweb-data-
protocol-06 (work in progress), June 2014. protocol-07 (work in progress), July 2014.
[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-04 (work in progress), May 2014. dtls-encaps-05 (work in progress), July 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-07 (work in progress), July 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-10 (work in progress), July 2014.
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work Session Establishment Protocol", draft-ietf-rtcweb-jsep-07
in progress), February 2014. (work in progress), July 2014.
[I-D.ietf-tsvwg-sctp-prpolicies] [I-D.ietf-tsvwg-sctp-prpolicies]
Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
"Additional Policies for the Partial Reliability Extension "Additional Policies for the Partial Reliability Extension
of the Stream Control Transmission Protocol", draft-ietf- of the Stream Control Transmission Protocol", draft-ietf-
tsvwg-sctp-prpolicies-03 (work in progress), May 2014. tsvwg-sctp-prpolicies-03 (work in progress), May 2014.
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Loreto, S. and G. Camarillo, "Stream Control Transmission Loreto, S. and G. Camarillo, "Stream Control Transmission
Protocol (SCTP)-Based Media Transport in the Session Protocol (SCTP)-Based Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-06 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07
(work in progress), February 2014. (work in progress), July 2014.
10.2. Informative References 10.2. Informative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[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 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host Control Transmission Protocol (SCTP) Packets for End-Host
 End of changes. 35 change blocks. 
81 lines changed or deleted 148 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/