idnits 2.17.1 draft-ietf-clue-datachannel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2014) is 3504 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-05 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-11 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-07 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-01 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-sctp-prpolicies-03 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track September 15, 2014 5 Expires: March 19, 2015 7 CLUE Protocol Data Channel 8 draft-ietf-clue-datachannel-01 10 Abstract 12 This document defines how to use the WebRTC Data Channel mechanism, 13 together with the Data Channel Establishment Protocol (DCEP) in order 14 to establish a data channel, referred to as CLUE Data Channel, for 15 transporting CLUE protocol messages between two CLUE entities. 17 The document defines the SCTP considerations specific to a CLUE Data 18 Channel, the SDP offer/answer procedures for negotiating the 19 establishment of, and the DCEP procedures for opening, a CLUE Data 20 Channel. 22 Details and procedures associated with the CLUE protocol are outside 23 the scope of this document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 19, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. CLUE Data Channel . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Data Channel Establishment Protocol (DCEP) Usage . . . . 4 64 3.3. SCTP Considerations . . . . . . . . . . . . . . . . . . . 4 65 3.3.1. SCTP Payload Protocol Identifier (PPID) . . . . . . . 4 66 3.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 5 67 3.3.3. Order . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.3.4. Stream Reset . . . . . . . . . . . . . . . . . . . . 5 69 3.3.5. Interleaving . . . . . . . . . . . . . . . . . . . . 6 70 3.3.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 6 71 4. CLUE Data Channel Procedures . . . . . . . . . . . . . . . . 6 72 4.1. Open CLUE Data Channel . . . . . . . . . . . . . . . . . 6 73 4.2. Close CLUE Data Channel . . . . . . . . . . . . . . . . . 6 74 4.3. SCTP Association Failure . . . . . . . . . . . . . . . . 7 75 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 76 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5.2. SDP Media Description Fields . . . . . . . . . . . . . . 7 78 5.3. SDP sctpmap Attribute . . . . . . . . . . . . . . . . . . 8 79 5.4. Generating the Initial Offer . . . . . . . . . . . . . . 8 80 5.5. Generating the Answer . . . . . . . . . . . . . . . . . . 8 81 5.6. Offerer Processing of the Answer . . . . . . . . . . . . 9 82 5.7. Modifying the Session . . . . . . . . . . . . . . . . . . 9 83 5.8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 87 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 10.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 This document defines how to use the WebRTC Data Channel mechanism 96 [I-D.ietf-rtcweb-data-channel], together with the Data Channel 97 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] in 98 order to establish a data channel, referred to as CLUE Data Channel, 99 for transporting CLUE protocol [I-D.ietf-clue-protocol] messages 100 between CLUE entities. 102 The document defines the SCTP considerations specific to a CLUE Data 103 Channel, the SDP offer/answer [RFC3264] procedures for negotiating 104 the establishment of, and the DCEP procedures for opening, a CLUE 105 Data Channel. 107 Details and procedures associated with the CLUE protocol are outside 108 the scope of this document. 110 2. Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14, RFC 2119 115 [RFC2119]. 117 WebRTC Data Channel refers to a SCTPoDTLS association 118 [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media 119 data between two entities, according to the procedures in 120 [I-D.ietf-rtcweb-data-channel]. 122 CLUE Data Channel refers to a WebRTC Data Channel 123 [I-D.ietf-rtcweb-data-channel], with a specific set of SCTP 124 characteristics, and usage of the Data Channel Establishment Protocol 125 (DCEP) [I-D.ietf-rtcweb-data-protocol] in order to open a WebRTC Data 126 Channel for the purpose of transporting CLUE protocol 127 [I-D.ietf-clue-protocol] messages between two CLUE entities. 129 CLUE entity refers to a SIP User Agent (UA) [RFC3261] that supports 130 the CLUE Data Channel and the CLUE protocol. 132 CLUE session refers to a SIP session [RFC3261] between to SIP UAs, 133 where a CLUE Data Channel, associated with the SIP session, has been 134 established between the SIP UAs. 136 [RFC4960] defines an SCTP stream as a unidirectional logical channel 137 established from one to another associated SCTP endpoint, within 138 which all user messages are delivered in sequence except for those 139 submitted to the unordered delivery service. 141 [RFC4960] defines an SCTP identifier as a unsigned integer, which 142 identifies a SCTP stream. 144 3. CLUE Data Channel 146 3.1. General 148 This section describes the realization of a CLUE Data Channel. This 149 includes a set of SCTP characteristics specific to a CLUE Data 150 Channel, and usage of the Data Channel Establishment Protocol (DCEP) 151 [I-D.ietf-rtcweb-data-protocol] in order to open a WebRTC Data 152 Channel for the purpose of transporting CLUE protocol 153 [I-D.ietf-clue-protocol] messages between two CLUE entities. 155 As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams 156 realizing a WebRTC Data Channel must be associated with the same SCTP 157 association. In addition, both SCTP streams realizing the WebRTC 158 Data Channel must use the same SCTP stream identifier value. These 159 rules also apply to a CLUE Data Channel. 161 Within a given CLUE session, a CLUE entity MUST use a single CLUE 162 Data Channel for transport of all CLUE messages towards its peer. 164 3.2. Data Channel Establishment Protocol (DCEP) Usage 166 A CLUE entity MUST support the Data Channel Establishment Protocol 167 (DCEP) [I-D.ietf-rtcweb-data-channel], which can be used in order to 168 open a WebRTC Data Channel. 170 In the absence of some other mechanism, a CLUE entity MUST use DCEP 171 in order to open a CLUE Data Channel. 173 NOTE: This document does not define any other mechanism for opening a 174 CLUE Data Channel, but such might be defined in future 175 specifications. 177 The details of the DCEP usage with a CLUE Data Channel are described 178 in Section 4.1. 180 3.3. SCTP Considerations 182 3.3.1. SCTP Payload Protocol Identifier (PPID) 184 As described in [I-D.ietf-rtcweb-data-protocol], the PPID value 50 is 185 used when sending a DCEP message on a WebRTC Data Channel. 187 A CLUE entity MUST use the PPID value 51 when sending a CLUE message 188 on a CLUE Data Channel. 190 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 191 51 indicates that the SCTP message contains data encoded in a UTF-8 192 format. The PPID value 51 does not indicate what application 193 protocol is transported in a WebRTC Data Channel, only the format in 194 which the data is encoded. 196 +----------+------------+ 197 | Protocol | PPID Value | 198 +----------+------------+ 199 | DCEP | 50 | 200 | CLUE | 51 | 201 +----------+------------+ 203 Table 1: CLUE Data Channel PPID Values 205 3.3.2. Reliability 207 The usage of SCTP for the CLUE Data Channel ensures reliable 208 transport of CLUE protocol [I-D.ietf-clue-protocol] messages. 210 A CLUE entity MUST NOT use the partial reliability and limited 211 retransmission extensions defined in [RFC3758]. 213 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 214 partial reliability extension defined in [RFC3758]. This is not 215 needed for a CLUE Data Channel, as messages are required to always be 216 sent reliably. [I-D.ietf-rtcweb-data-channel] also mandates support 217 of the limited retransmission policy defined in 218 [I-D.ietf-tsvwg-sctp-prpolicies]. 220 3.3.3. Order 222 A CLUE entity MUST use the ordered delivery SCTP service, as 223 described in section 6.6 of [RFC4960]. 225 3.3.4. Stream Reset 227 A CLUE entity MUST support the stream reset extension defined in 228 [RFC6525]. 230 The dynamic address reconfiguration extension defined in [RFC5061] 231 MUST be used to signal the support of the stream reset extension 232 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 234 3.3.5. Interleaving 236 A CLUE entity MUST support the message interleaving mechanism defined 237 in [I-D.ietf-tsvwg-sctp-ndata]. 239 3.3.6. SCTP Multihoming 241 SCTP multihoming cannot be used for a CLUE Data Channel. 243 NOTE: SCTPoDTLS does not support SCTP multihoming. 245 4. CLUE Data Channel Procedures 247 4.1. Open CLUE Data Channel 249 Once the SCTP association, to be used to realized the CLUE Data 250 Channel, has been established, the offerer [RFC3264] is responsible 251 for opening the CLUE Data Channel. If DCEP is used, the offerer MUST 252 send a DCEP DATA_CHANNEL_OPEN message 253 [I-D.ietf-rtcweb-data-protocol]. The value of the 'protocol' field 254 MUST be "CLUE". The value of the 'channel type' MUST be 255 'DATA_CHANNEL_RELIABLE'. 257 OPEN ISSUE: We need to determine whether we shall include a version 258 number in the 'protocol' field value for CLUE. 260 NOTE: A new 'protocol' value for CLUE needs to be registered with 261 IANA in the 'Protocol Registry' defined by 262 [I-D.ietf-rtcweb-data-protocol]. 264 Once the offerer has received the associated DCEP DATA_CHANNEL_ACK 265 message [I-D.ietf-rtcweb-data-protocol], the CLUE Data channel has 266 been opened. 268 If the offerer receives a DCEP DATA_CHANNEL_OPEN message, for the 269 purpose of opening a CLUE Data Channel, the offerer MUST reset the 270 SCTP stream, in order to prevent two CLUE Data Channels from being 271 established within the same CLUE session. The offerer MUST NOT send 272 a DCEP DATA_CHANNEL_ACK message. 274 4.2. Close CLUE Data Channel 276 DCEP [I-D.ietf-rtcweb-data-protocol] does not define a message for 277 closing a WebRTC Data Channel. As described in 278 [I-D.ietf-rtcweb-data-protocol], in order to close a CLUE Data 279 Channel, a SCTP reset message is sent, in order to close the SCTP 280 stream associated with the CLUE Data Channel. The SCTP association, 281 and WebRTC Data Channels associated with other SCTP streams, are not 282 affected by the SCTP reset message. 284 Section 5.7 describes how to terminate the SCTP association used for 285 the CLUE data channel. 287 4.3. SCTP Association Failure 289 In case of SCTP association failure, the offerer is responsible for 290 trying to re-establish the SCTP association (including sending a new 291 SDP offer, if needed). Once the SCTP association has been 292 successfully re-established, the offerer is responsible for sending a 293 DCEP DATA_CHANNEL_OPEN message. 295 5. SDP Offer/Answer Procedures 297 5.1. General 299 This section describes how an SDP media description ("m=") line 300 describing a SCTPoDTLS association, to be used to realize a CLUE Data 301 Channel, is created, and how it is used in SDP offers and answers 302 [RFC3264]. 304 NOTE: The procedures associated with creating an "m=" line describing 305 media (e.g. audio and video) for a CLUE session are outside the scope 306 of this document. 308 OPEN ISSUE (Q1): It is FFS whether the SDP-based WebRTC Data Channel 309 Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 310 will be used with the CLUE Data Channel. It depends on whether the 311 draft will progress in MMUSIC, and whether it will be finalized 312 before the publication of the CLUE mechanism. 314 OPEN ISSUE (Q2): As the SDP offer/answer procedures are generic to 315 SCTPoDTLS association, it is FFS whether we need to specify them, or 316 whether we can simply refer to draft-ietf-mmusic-sctp-sdp. 318 5.2. SDP Media Description Fields 320 The field values of the "m=" line for the SCTPoDTLS association are 321 set as following: 323 +---------------+-----------------+-------------+-----------------+ 324 | media | port | proto | fmt | 325 +---------------+-----------------+-------------+-----------------+ 326 | "application" | DTLS port value | "DTLS/SCTP" | SCTP port value | 327 +---------------+-----------------+-------------+-----------------+ 329 Table 2: SDP "proto" field values 331 5.3. SDP sctpmap Attribute 333 The field values of the SDP sctpmap attribute, associated with the 334 "m=" line describing the SCTPoDTLS association, are set as following: 336 +----------------------------+----------------------+ 337 | sctpmap-number | app | 338 +----------------------------+----------------------+ 339 | fmt value of the "m=" line | "webrtc-datachannel" | 340 +----------------------------+----------------------+ 342 Table 3: SDP "proto" field values 344 5.4. Generating the Initial Offer 346 The procedures for the offerer follow the normal procedures defined 347 in [RFC3264]. 349 When the offerer creates an offer, which contains an "m=" line 350 describing a SCTPoDTLS association, it assigns the field values to 351 the "m=" line according to the procedures in Section 5.2. In 352 addition, the offerer MUST insert an SDP sctpmap attribute associated 353 with the "m=" line. 355 If an offerer, in a subsequent offer, wants to disable the CLUE Data 356 Channel, it assigns a zero port value to the "m=" line describing the 357 SCTPoDTLS association used to realize the CLUE Data Channel. 359 5.5. Generating the Answer 361 The procedures for the answerer follow the normal procedures defined 362 in [RFC3264]. 364 If the answerer receives an offer, which contains an "m=" line 365 describing a SCTPoDTLS association, and the answerer accepts the "m=" 366 line, it inserts an "m=" line in the corresponding answer, and 367 assigns the "m=" line field values according to the procedures in 368 Section 4.2. 370 If the answerer receives an offer, which contains an "m=" line 371 describing a SCTPoDTLS association, and the answerer does not accept 372 the "m=" line, it inserts an "m=" line in the corresponding answer, 373 and assigns a zero port value to the "m=" line, according to the 374 procedures in [RFC3264]. 376 If the answerer receives an offer, in which a zero port value has 377 been assigned to an "m=" line describing the SCTPoDTLS association, 378 it inserts an "m=" line in the corresponding answer, and assigns a 379 zero port value to the "m=" line, according to the procedures in 380 [RFC3264] 382 OPEN ISSUE (Q3): We need to determine whether an "m=" line describing 383 an SCTPoDTLS association can be used together with bundle-only, in 384 which case there will be cases where an offer with a zero port value 385 will create a corresponding answer with a non-zero port value. 387 5.6. Offerer Processing of the Answer 389 When the offerer receives an SDP answer and, if the offerer ends up 390 being active it MUST initiate a DTLS handshake by sending a DTLS 391 ClientHello message on the negotiated media stream, towards the IP 392 address and port of the answerer. 394 5.7. Modifying the Session 396 Once an offer/answer exchange has been completed, either endpoint MAY 397 send a new offer in order to modify the session. The endpoints can 398 reuse the existing SCTPoDTLS association if the key fingerprint 399 values and transport parameters indicated by each endpoint are 400 unchanged are unchanged. Otherwise, following the rules as for the 401 initial offer/answer exchange, the endpoints can negotiate and create 402 a new SCTPoDTLS association and, once created, delete the previous 403 SCTPoDTLS association, following the same rules of for the initial 404 offer/answer exchange. 406 If an offerer wants to disable the CLUE Data Channel in an offer, it 407 assigns a zero port value to the "m=" line representing the SCTPoDTLS 408 association used to realize the CLUE Data channel. 410 5.8. Example 412 m=application 54111 SCTP/DTLS 54111 413 a=sctpmap:54111 webrtc-datachannel 415 Figure 1: SDP Media Description for a CLUE Data Channel 417 6. Security Considerations 419 This specification does not introduce new security considerations, in 420 addition to those defined in [ref-to-data-channel] and [ref-to-data- 421 protocol]. Security considerations associated with the CLUE protocol 422 are defined in [ref-to-clue-protocol]. 424 7. IANA Considerations 426 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 427 document.] 429 8. Acknowledgments 431 Thanks to Paul Kyzivat and Christian Groves for comments on the 432 document. 434 9. Change Log 436 [RFC EDITOR NOTE: Please remove this section when publishing] 438 Changes from draft-ietf-clue-datachannel-00 440 o SDP Offer/Answer procedures structures according to RFC 3264. 441 o Reference update. 443 Changes from draft-holmberg-clue-datachannel-04 445 o Draft submitted as draft-ietf-clue-data-channel-00. 446 o Editorial nits fixed. 447 o Changes based on comments from Paul Kyzivat (http://www.ietf.org/ 448 mail-archive/web/clue/current/msg03559.html). 449 o - Proto value fixed. 450 o - Explicit text that the partial reliability and limited 451 retransmission policies MUST NOT be used. 452 o - Added open issue on whether the DCEP 'protocol' field value for 453 CLUE should contain a version number. 454 o - Removed paragraph saying that an offerer must not insert more 455 than one m- line describing an SCTPoDTLS association to be used to 456 realize a CLUE Data Channel, as the draft already states that only 457 one CLUE Data Channel per CLUE session shall be opened. 458 o - Added reference to draft-ietf-rtcweb-data-protocol regarding 459 details on reseting SCTP streams. 460 o - Added text saying that the value of the DCEP 'channel type' MUST 461 be DATA_CHANNEL_RELIABLE. 462 o - Clarified that DCEP must be supported, and used in the absence 463 of another mechanism for opening a CLUE Data Channel. 465 Changes from draft-holmberg-clue-datachannel-03 467 o Procedures updated, based on WG agreement (IETF#89) to use DCEP 468 for the CLUE data channel. 469 o Procedures updated, based on WG agreement (IETF#89) that offerer 470 is responsible for sending DCEP DATA_CHANNEL_OPEN. 471 o Editorial changes, and alignments caused by changes in referenced 472 specifications. 474 Changes from draft-holmberg-clue-datachannel-02 476 o PPID value for CLUE messages added 477 o References updated 479 Changes from draft-holmberg-clue-datachannel-01 481 o More text added 483 Changes from draft-holmberg-clue-datachannel-00 485 o Editorial corrections based on comments from Paul K 487 10. References 489 10.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 495 A., Peterson, J., Sparks, R., Handley, M., and E. 496 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 497 June 2002. 499 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 500 with Session Description Protocol (SDP)", RFC 3264, June 501 2002. 503 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 504 4960, September 2007. 506 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 507 Kozuka, "Stream Control Transmission Protocol (SCTP) 508 Dynamic Address Reconfiguration", RFC 5061, September 509 2007. 511 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 512 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 513 6525, February 2012. 515 [I-D.ietf-clue-protocol] 516 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 517 clue-protocol-01.txt (work in progress), June 2014. 519 [I-D.ietf-tsvwg-sctp-dtls-encaps] 520 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 521 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 522 dtls-encaps-05.txt (work in progress), July 2014. 524 [I-D.ietf-rtcweb-data-channel] 525 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 526 Channels", draft-ietf-rtcweb-data-channel-11.txt (work in 527 progress), July 2014. 529 [I-D.ietf-rtcweb-data-protocol] 530 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 531 Establishment Protocol", draft-ietf-rtcweb-data-protocol- 532 07.txt (work in progress), July 2014. 534 [I-D.ietf-tsvwg-sctp-ndata] 535 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 536 "Stream Schedulers and a New Data Chunk for the Stream 537 Control Transmission Protocol", draft-ietf-tsvwg-sctp- 538 ndata-01.txt (work in progress), July 2014. 540 [I-D.ietf-tsvwg-sctp-prpolicies] 541 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 542 "Additional Policies for the Partial Reliability Extension 543 of the Stream Control Transmission Protocol", draft-ietf- 544 tsvwg-sctp-prpolicies-03.txt (work in progress), October 545 2014. 547 10.2. Informative References 549 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 550 Conrad, "Stream Control Transmission Protocol (SCTP) 551 Partial Reliability Extension", RFC 3758, May 2004. 553 [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 554 Ejzak, R. and J. Marcon, "SDP-based WebRTC data channel 555 negotiation", draft-ejzak-dispatch-webrtc-data-channel- 556 sdpneg-00.txt (work in progress), October 2013. 558 Author's Address 560 Christer Holmberg 561 Ericsson 562 Hirsalantie 11 563 Jorvas 02420 564 Finland 566 Email: christer.holmberg@ericsson.com