idnits 2.17.1 draft-ietf-clue-datachannel-00.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 (March 20, 2014) is 3680 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 (-04) exists of draft-presta-clue-protocol-03 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-07 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-03 ** Downref: Normative reference to an Informational draft: draft-tuexen-tsvwg-sctp-prpolicies (ref. 'I-D.tuexen-tsvwg-sctp-prpolicies') Summary: 2 errors (**), 0 flaws (~~), 5 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 March 20, 2014 5 Expires: September 21, 2014 7 CLUE Protocol Data Channel 8 draft-ietf-clue-datachannel-00 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 September 21, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . 5 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. SDP Offerer Procedures . . . . . . . . . . . . . . . . . 8 80 5.5. SDP Answerer Procedures . . . . . . . . . . . . . . . . . 8 81 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 85 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 10.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 This document defines how to use the WebRTC Data Channel mechanism 94 [I-D.ietf-rtcweb-data-channel], together with the Data Channel 95 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] in 96 order to establish a data channel, referred to as CLUE Data Channel, 97 for transporting CLUE protocol [I-D.presta-clue-protocol] messages 98 between CLUE entities. 100 The document defines the SCTP considerations specific to a CLUE Data 101 Channel, the SDP offer/answer [RFC3264] procedures for negotiating 102 the establishment of, and the DCEP procedures for opening, a CLUE 103 Data Channel. 105 Details and procedures associated with the CLUE protocol are outside 106 the scope of this document. 108 2. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, RFC 2119 113 [RFC2119]. 115 WebRTC Data Channel refers to a SCTPoDTLS association 116 [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media 117 data between two entities, according to the procedures in 118 [I-D.ietf-rtcweb-data-channel]. 120 CLUE Data Channel refers to a WebRTC Data Channel 121 [I-D.ietf-rtcweb-data-channel], with a specific set of SCTP 122 characteristics, and usage of the Data Channel Establishment Protocol 123 (DCEP) [I-D.ietf-rtcweb-data-protocol] in order to open a WebRTC Data 124 Channel for the purpose of transporting CLUE protocol 125 [I-D.presta-clue-protocol] messages between two CLUE entities. 127 CLUE entity refers to a SIP User Agent (UA) [RFC3261] that supports 128 the CLUE Data Channel and the CLUE protocol. 130 CLUE session refers to a SIP session [RFC3261] between to SIP UAs, 131 where a CLUE Data Channel, associated with the SIP session, has been 132 established between the SIP UAs. 134 [RFC4960] defines an SCTP stream as a unidirectional logical channel 135 established from one to another associated SCTP endpoint, within 136 which all user messages are delivered in sequence except for those 137 submitted to the unordered delivery service. 139 [RFC4960] defines an SCTP identifier as a unsigned integer, which 140 identifies a SCTP stream. 142 3. CLUE Data Channel 144 3.1. General 146 This section describes the realization of a CLUE Data Channel. This 147 includes a set of SCTP characteristics specific to a CLUE Data 148 Channel, and usage of the Data Channel Establishment Protocol (DCEP) 149 [I-D.ietf-rtcweb-data-protocol] in order to open a WebRTC Data 150 Channel for the purpose of transporting CLUE protocol 151 [I-D.presta-clue-protocol] messages between two CLUE entities. 153 As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams 154 realizing a WebRTC Data Channel must be associated with the same SCTP 155 association. In addition, both SCTP streams realizing the WebRTC 156 Data Channel must use the same SCTP stream identifier value. These 157 rules also apply to a CLUE Data Channel. 159 Within a given CLUE session, a CLUE entity MUST use a single CLUE 160 Data Channel for transport of all CLUE messages towards its peer. 162 3.2. Data Channel Establishment Protocol (DCEP) Usage 164 A CLUE entity MUST support the Data Channel Establishment Protocol 165 (DCEP) [I-D.ietf-rtcweb-data-channel], which can be used in order to 166 open a WebRTC Data Channel. 168 In the absence of some other mechanism, a CLUE entity MUST use DCEP 169 in order to open a CLUE Data Channel. 171 NOTE: This document does not define any other mechanism for opening a 172 CLUE Data Channel, but such might be defined in future 173 specifications. 175 The details of the DCEP usage with a CLUE Data Channel are described 176 in Section 4.1. 178 3.3. SCTP Considerations 180 3.3.1. SCTP Payload Protocol Identifier (PPID) 182 As described in [I-D.ietf-rtcweb-data-protocol], the PPID value 50 is 183 used when sending a DCEP message on a WebRTC Data Channel. 185 A CLUE entity MUST use the PPID value 51 when sending a CLUE message 186 on a CLUE Data Channel. 188 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 189 51 indicates that the SCTP message contains data encoded in a UTF-8 190 format. The PPID value 51 does not indicate what application 191 protocol is transported in a WebRTC Data Channel, only the format in 192 which the data is encoded. 194 +----------+------------+ 195 | Protocol | PPID Value | 196 +----------+------------+ 197 | DCEP | 50 | 198 | CLUE | 51 | 199 +----------+------------+ 201 Table 1: CLUE Data Channel PPID Values 203 3.3.2. Reliability 205 The usage of SCTP for the CLUE Data Channel ensures reliable 206 transport of CLUE protocol [I-D.presta-clue-protocol] messages. 208 A CLUE entity MUST NOT use the partial reliability and limited 209 retransmission extensions defined in [RFC3758]. 211 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 212 partial reliability extension defined in [RFC3758]. This is not 213 needed for a CLUE Data Channel, as messages are required to always be 214 sent reliably. [I-D.ietf-rtcweb-data-channel] also mandates support 215 of the limited retransmission policy defined in 216 [I-D.tuexen-tsvwg-sctp-prpolicies]. 218 3.3.3. Order 220 A CLUE entity MUST use the ordered delivery SCTP service, as 221 described in section 6.6 of [RFC4960]. 223 3.3.4. Stream Reset 225 A CLUE entity MUST support the stream reset extension defined in 226 [RFC6525]. 228 The dynamic address reconfiguration extension defined in [RFC5061] 229 MUST be used to signal the support of the stream reset extension 230 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 232 3.3.5. Interleaving 234 A CLUE entity MUST support the message interleaving mechanism defined 235 in [I-D.stewart-tsvwg-sctp-ndata]. 237 3.3.6. SCTP Multihoming 239 SCTP multihoming cannot be used for a CLUE Data Channel. 241 NOTE: SCTPoDTLS does not support SCTP multihoming. 243 4. CLUE Data Channel Procedures 245 4.1. Open CLUE Data Channel 247 Once the SCTP association, to be used to realized the CLUE Data 248 Channel, has been established, the offerer [RFC3264] is responsible 249 for opening the CLUE Data Channel. If DCEP is used, the offerer MUST 250 send a DCEP DATA_CHANNEL_OPEN message 251 [I-D.ietf-rtcweb-data-protocol]. The value of the 'protocol' field 252 MUST be "CLUE". The value of the 'channel type' MUST be 253 'DATA_CHANNEL_RELIABLE'. 255 OPEN ISSUE: We need to determine whether we shall include a version 256 number in the 'protocol' field value for CLUE. 258 NOTE: A new 'protocol' value for CLUE needs to be registered with 259 IANA in the 'Protocol Registry' defined by 260 [I-D.ietf-rtcweb-data-protocol]. 262 Once the offerer has received the associated DCEP DATA_CHANNEL_ACK 263 message [I-D.ietf-rtcweb-data-protocol], the CLUE Data channel has 264 been opened. 266 If the offerer receives a DCEP DATA_CHANNEL_OPEN message, for the 267 purpose of opening a CLUE Data Channel, the offerer MUST reset the 268 SCTP stream, in order to prevent two CLUE Data Channels from being 269 established within the same CLUE session. The offerer MUST NOT send 270 a DCEP DATA_CHANNEL_ACK message. 272 4.2. Close CLUE Data Channel 274 DCEP [I-D.ietf-rtcweb-data-protocol] does not define a message for 275 closing a WebRTC Data Channel. As described in 276 [I-D.ietf-rtcweb-data-protocol], in order to close a CLUE Data 277 Channel, a SCTP reset message is sent, in order to close the SCTP 278 stream associated with the CLUE Data Channel. The SCTP association, 279 and WebRTC Data Channels associated with other SCTP streams, are not 280 affected by the SCTP reset message. 282 Section 5.4 describes how to terminate the SCTP association used for 283 the CLUE data channel. 285 4.3. SCTP Association Failure 287 In case of SCTP association failure, the offerer is responsible for 288 trying to re-establish the SCTP association (including sending a new 289 SDP offer, if needed). Once the SCTP association has been 290 successfully re-established, the offerer is responsible for sending a 291 DCEP DATA_CHANNEL_OPEN message. 293 5. SDP Offer/Answer Procedures 295 5.1. General 297 This section describes how an SDP media description ("m=") line 298 describing a SCTPoDTLS association, to be used to realize a CLUE Data 299 Channel, is created, and how it is used in SDP offers and answers 300 [RFC3264]. 302 NOTE: The procedures associated with creating an "m=" line describing 303 media (e.g. audio and video) for a CLUE session are outside the scope 304 of this document. 306 OPEN ISSUE (Q1): It is FFS whether the SDP-based WebRTC Data Channel 307 Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 308 will be used with the CLUE Data Channel. It depends on whether the 309 draft will progress in MMUSIC, and whether it will be finalized 310 before the publication of the CLUE mechanism. 312 OPEN ISSUE (Q2): As the SDP offer/answer procedures are generic to 313 SCTPoDTLS association, it is FFS whether we need to specify them, or 314 whether we can simply refer to draft-ietf-mmusic-sctp-sdp. 316 5.2. SDP Media Description Fields 318 The field values of the "m=" line for the SCTPoDTLS association are 319 set as following: 321 +---------------+-----------------+-------------+-----------------+ 322 | media | port | proto | fmt | 323 +---------------+-----------------+-------------+-----------------+ 324 | "application" | DTLS port value | "DTLS/SCTP" | SCTP port value | 325 +---------------+-----------------+-------------+-----------------+ 327 Table 2: SDP "proto" field values 329 5.3. SDP sctpmap Attribute 331 The field values of the SDP sctpmap attribute, associated with the 332 "m=" line describing the SCTPoDTLS association, are set as following: 334 +----------------------------+----------------------+ 335 | sctpmap-number | app | 336 +----------------------------+----------------------+ 337 | fmt value of the "m=" line | "webrtc-datachannel" | 338 +----------------------------+----------------------+ 340 Table 3: SDP "proto" field values 342 5.4. SDP Offerer Procedures 344 The procedures for the offerer follow the normal procedures defined 345 in [RFC3264]. 347 When the offerer creates an offer, which contains an "m=" line 348 describing a SCTPoDTLS association, it assigns the field values to 349 the "m=" line according to the procedures in Section 5.2. In 350 addition, the offerer MUST insert an SDP sctpmap attribute associated 351 with the "m=" line. 353 If an offerer, in a subsequent offer, wants to disable the CLUE Data 354 Channel, it assigns a zero port value to the "m=" line describing the 355 SCTPoDTLS association used to realize the CLUE Data Channel. 357 5.5. SDP Answerer Procedures 359 The procedures for the answerer follow the normal procedures defined 360 in [RFC3264]. 362 If the answerer receives an offer, which contains an "m=" line 363 describing a SCTPoDTLS association, and the answerer accepts the "m=" 364 line, it inserts an "m=" line in the corresponding answer, and 365 assigns the "m=" line field values according to the procedures in 366 Section 4.2. 368 If the answerer receives an offer, which contains an "m=" line 369 describing a SCTPoDTLS association, and the answerer does not accept 370 the "m=" line, it inserts an "m=" line in the corresponding answer, 371 and assigns a zero port value to the "m=" line, according to the 372 procedures in [RFC3264]. 374 If the answerer receives an offer, in which a zero port value has 375 been assigned to an "m=" line describing the SCTPoDTLS association, 376 it inserts an "m=" line in the corresponding answer, and assigns a 377 zero port value to the "m=" line, according to the procedures in 378 [RFC3264] 380 OPEN ISSUE (Q3): We need to determine whether an "m=" line describing 381 an SCTPoDTLS association can be used together with bundle-only, in 382 which case there will be cases where an offer with a zero port value 383 will create a corresponding answer with a non-zero port value. 385 5.6. Example 387 m=application 54111 SCTP/DTLS 54111 388 a=sctpmap:54111 webrtc-datachannel 390 Figure 1: SDP Media Description for a CLUE Data Channel 392 6. Security Considerations 394 This specification does not introduce new security considerations, in 395 addition to those defined in [ref-to-data-channel] and [ref-to-data- 396 protocol]. Security considerations associated with the CLUE protocol 397 are defined in [ref-to-clue-protocol]. 399 7. IANA Considerations 401 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 402 document.] 404 8. Acknowledgments 406 Thanks to Paul Kyzivat and Christian Groves for comments on the 407 document. 409 9. Change Log 411 [RFC EDITOR NOTE: Please remove this section when publishing] 413 Changes from draft-holmberg-clue-datachannel-04 415 o Draft submitted as draft-ietf-clue-data-channel-00. 416 o Editorial nits fixed. 417 o Changes based on comments from Paul Kyzivat (http://www.ietf.org/ 418 mail-archive/web/clue/current/msg03559.html). 419 o - Proto value fixed. 420 o - Explicit text that the partial reliability and limited 421 retransmission policies MUST NOT be used. 422 o - Added open issue on whether the DCEP 'protocol' field value for 423 CLUE should contain a version number. 425 o - Removed paragraph saying that an offerer must not insert more 426 than one m- line describing an SCTPoDTLS association to be used to 427 realize a CLUE Data Channel, as the draft already states that only 428 one CLUE Data Channel per CLUE session shall be opened. 429 o - Added reference to draft-ietf-rtcweb-data-protocol regarding 430 details on reseting SCTP streams. 431 o - Added text saying that the value of the DCEP 'channel type' MUST 432 be DATA_CHANNEL_RELIABLE. 433 o - Clarified that DCEP must be supported, and used in the absence 434 of another mechanism for opening a CLUE Data Channel. 436 Changes from draft-holmberg-clue-datachannel-03 438 o Procedures updated, based on WG agreement (IETF#89) to use DCEP 439 for the CLUE data channel. 440 o Procedures updated, based on WG agreement (IETF#89) that offerer 441 is responsible for sending DCEP DATA_CHANNEL_OPEN. 442 o Editorial changes, and alignments caused by changes in referenced 443 specifications. 445 Changes from draft-holmberg-clue-datachannel-02 447 o PPID value for CLUE messages added 448 o References updated 450 Changes from draft-holmberg-clue-datachannel-01 452 o More text added 454 Changes from draft-holmberg-clue-datachannel-00 456 o Editorial corrections based on comments from Paul K 458 10. References 460 10.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 466 A., Peterson, J., Sparks, R., Handley, M., and E. 467 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 468 June 2002. 470 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 471 with Session Description Protocol (SDP)", RFC 3264, June 472 2002. 474 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 475 4960, September 2007. 477 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 478 Kozuka, "Stream Control Transmission Protocol (SCTP) 479 Dynamic Address Reconfiguration", RFC 5061, September 480 2007. 482 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 483 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 484 6525, February 2012. 486 [I-D.presta-clue-protocol] 487 Presta, R. and S. Romano, "CLUE protocol", draft-presta- 488 clue-protocol-03.txt (work in progress), November 2013. 490 [I-D.ietf-tsvwg-sctp-dtls-encaps] 491 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 492 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 493 dtls-encaps-03.txt (work in progress), February 2014. 495 [I-D.ietf-rtcweb-data-channel] 496 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 497 Channels", draft-ietf-rtcweb-data-channel-07.txt (work in 498 progress), February 2014. 500 [I-D.ietf-rtcweb-data-protocol] 501 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 502 Establishment Protocol", draft-ietf-rtcweb-data- 503 protocol-03.txt (work in progress), February 2014. 505 [I-D.stewart-tsvwg-sctp-ndata] 506 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 507 New Data Chunk for Stream Control Transmission Protocol", 508 draft-stewart-tsvwg-sctp-ndata-03.txt (work in progress), 509 October 2013. 511 [I-D.tuexen-tsvwg-sctp-prpolicies] 512 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 513 "Additional Policies for the Partial Delivery Extension of 514 the Stream Control Transmission Protocol", draft-tuexen- 515 tsvwg-sctp-prpolicies-03.txt (work in progress), October 516 2013. 518 10.2. Informative References 520 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 521 Conrad, "Stream Control Transmission Protocol (SCTP) 522 Partial Reliability Extension", RFC 3758, May 2004. 524 [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 525 Ejzak, R. and J. Marcon, "SDP-based WebRTC data channel 526 negotiation", draft-ejzak-dispatch-webrtc-data-channel- 527 sdpneg-00.txt (work in progress), October 2013. 529 Author's Address 531 Christer Holmberg 532 Ericsson 533 Hirsalantie 11 534 Jorvas 02420 535 Finland 537 Email: christer.holmberg@ericsson.com