idnits 2.17.1 draft-holmberg-clue-datachannel-04.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 13, 2014) is 3697 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 2960 (Obsoleted by RFC 4960) ** 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-02 == 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: 3 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 13, 2014 5 Expires: September 14, 2014 7 CLUE Protocol Data Channel 8 draft-holmberg-clue-datachannel-04 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 14, 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 . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 11 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 use the Data Channel Establishment Protocol (DCEP) 165 [I-D.ietf-rtcweb-data-channel], in order to open a CLUE Data Channel. 167 The details of the DCEP usage with a CLUE Data Channel are described 168 in section X.X.X. 170 3.3. SCTP Considerations 172 3.3.1. SCTP Payload Protocol Identifier (PPID) 174 As described in [I-D.ietf-rtcweb-data-protocol], the PPID value 50 is 175 used when sending a DCEP message on a WebRTC Data Channel. 177 A CLUE entity MUST use the PPID value 51 when sending a CLUE message 178 on a CLUE Data Channel. 180 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 181 51 indicates that the SCTP message contains data encoded in a UTF-8 182 format. The PPID value 51 does not indicate what application 183 protocol is transported in a WebRTC Data Channel, only the format in 184 which the data is encoded. 186 +----------+------------+ 187 | Protocol | PPID Value | 188 +----------+------------+ 189 | DCEP | 50 | 190 | CLUE | 51 | 191 +----------+------------+ 193 Table 1: CLUE Data Channel PPID Values 195 3.3.2. Reliability 197 The usage of SCTP for the CLUE Data Channel ensures reliable 198 transport of CLUE protocol [I-D.presta-clue-protocol] messages. 200 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 201 partial reliability extension defined in [RFC3758]. This is not 202 needed for a CLUE Data Channel, as messages are required to always be 203 sent reliably. [I-D.ietf-rtcweb-data-channel] also mandates support 204 of the limited retransmission policy defined in 205 [I-D.tuexen-tsvwg-sctp-prpolicies]. 207 3.3.3. Order 209 A CLUE entity MUST use the ordered delivery SCTP service, as 210 described in section 6.6 of [RFC2960]. 212 3.3.4. Stream Reset 214 A CLUE entity MUST support the stream reset extension defined in 215 [RFC6525]. 217 The dynamic address reconfiguration extension defined in [RFC5061] 218 MUST be used to signal the support of the stream reset extension 219 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 221 3.3.5. Interleaving 223 A CLUE entity MUST support the message interleaving mechanism defined 224 in [I-D.stewart-tsvwg-sctp-ndata]. 226 3.3.6. SCTP Multihoming 228 SCTP multihoming cannot be used for a CLUE Data Channel. 230 NOTE: SCTPoDTLS does not support SCTP multihoming. 232 4. CLUE Data Channel Procedures 234 4.1. Open CLUE Data Channel 236 Once the SCTP association, to be used to realized the CLUE Data 237 Channel, has been established, the offerer [RFC3264] is responsible 238 for opening the CLUE Data Channel. The offerer MUST send a DCEP 239 DATA_CHANNEL_OPEN message [I-D.ietf-rtcweb-data-protocol]. The value 240 of the 'protocol' field MUST be "CLUE". 242 NOTE: A new 'protocol' value for CLUE needs to be registered with 243 IANA in the 'Protocol Registry' defined by 244 [I-D.ietf-rtcweb-data-protocol]. 246 Once the offerer has received the associated DCEP DATA_CHANNEL_ACK 247 message [I-D.ietf-rtcweb-data-protocol], the CLUE Data channel has 248 been opened. 250 If the Offerer receives a DCEP DATA_CHANNEL_OPEN message, for the 251 purpose of opening a CLUE Data Channel, the offerer MUST reset the 252 SCTP stream, in order to prevent two CLUE Data Channels from being 253 established within the same CLUE session. The offerer MUST NOT send 254 a DCEP DATA_CHANNEL_ACK message. 256 4.2. Close CLUE Data Channel 258 DCEP [I-D.ietf-rtcweb-data-protocol] does not define a message for 259 closing a WebRTC Data Channel. Instead, in order to close a CLUE 260 Data Channel, a SCTP reset message is sent, in order to close the 261 SCTP stream associated with the CLUE Data Channel. The SCTP 262 association, and WebRTC Data Channels associated with other SCTP 263 streams, are not affected by the SCTP reset message. 265 Section X.X.X describes how to terminate the SCTP association used 266 for the CLUE data channel. 268 4.3. SCTP Association Failure 270 In case of SCTP association failure, the offerer is responsible for 271 trying to re-establish the SCTP association (including sending a new 272 SDP offer, if needed). Once the SCTP association has been 273 successfully re-established, the offerer is responsible for sending a 274 DCEP DATA_CHANNEL_OPEN message. 276 5. SDP Offer/Answer Procedures 278 5.1. General 280 This section describes how an SDP media description ("m=") line 281 describing a SCTPoDTLS association, to be used to realize a CLUE Data 282 Channel, is created, and how it is used in SDP offers and answers 283 [RFC3264]. 285 NOTE: The procedures associated with creating an "m=" line describing 286 media (e.g. audio and video) for a CLUE session are outside the scope 287 of this document. 289 OPEN ISSUE (Q1): It is FFS whether the SDP-based WebRTC Data Channel 290 Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 291 will be used with the CLUE Data Channel. It depends on whether the 292 draft will progress in MMUSIC, and whether it will be finalized 293 before the publication of the CLUE mechanism. 295 OPEN ISSUE (Q2): As the SDP offer/answer procedures are generic to 296 SCTPoDTLS association, it is FFS whether we need to specify them, or 297 whether we can simply refer to Salvatore's draft. 299 5.2. SDP Media Description Fields 301 The field values of the "m=" line for the SCTPoDTLS association are 302 set as following: 304 +---------------+----------------+-----------------+----------------+ 305 | media | port | proto | fmt | 306 +---------------+----------------+-----------------+----------------+ 307 | "applicationS | DTLS port | "UDP/TLS/UDPTL" | SCTP port | 308 | | value | | value | 309 +---------------+----------------+-----------------+----------------+ 311 Table 2: SDP "proto" field values 313 5.3. SDP sctpmap Attribute 315 The field values of the SDP sctpmap attribute, associated with the 316 "m=" line describing the SCTPoDTLS association, are set as following: 318 +----------------------------+----------------------+ 319 | sctpmap-number | app | 320 +----------------------------+----------------------+ 321 | fmt value of the "m=" line | "webrtc-datachannel" | 322 +----------------------------+----------------------+ 324 Table 3: SDP "proto" field values 326 5.4. SDP Offerer Procedures 328 The procedures for the offerer follow the normal procedures defined 329 in [RFC3264]. 331 When the offerer creates an offer, which contains an "m=" line 332 describing a SCTPoDTLS association, it assigns the field values to 333 the "m=" line according to the procedures in Section 5.2. In 334 addition, the offerer MUST insert an SDP sctpmap attribute associated 335 with the "m=" line. 337 In an offer, the offerer MUST NOT insert more than one "m=" line 338 describing an SCTPoDTLS association to be used to realize a CLUE Data 339 Channel. 341 If an offerer, in a subsequent offer, wants to disable the CLUE Data 342 Channel, it assigns a zero port value to the "m=" line describing the 343 SCTPoDTLS association used to realize the CLUE Data Channel. 345 5.5. SDP Answerer Procedures 347 The procedures for the answerer follow the normal procedures defined 348 in [RFC3264]. 350 If the answerer receives an offer, which contains an "m=" line 351 describing a SCTPoDTLS association, and the answerer accepts the "m=" 352 line, it inserts an "m=" line in the corresponding answer, and 353 assigns the "m=" line field values according to the procedures in 354 Section 4.2. 356 If the answerer receives an offer, which contains an "m=" line 357 describing a SCTPoDTLS association, and the answerer does not accept 358 the "m=" line, it inserts an "m=" line in the corresponding answer, 359 and assigns a zero port value to the "m=" line, according to the 360 procedures in [RFC3264]. 362 If the answerer receives an offer, in which a zero port value has 363 been assigned to an "m=" line describing the SCTPoDTLS association, 364 it inserts an "m=" line in the corresponding answer, and assigns a 365 zero port value to the "m=" line, according to the procedures in 366 [RFC3264] 368 OPEN ISSUE (Q3): We need to determine whether an "m=" line describing 369 an SCTPoDTLS association can be used together with bundle-only, in 370 which case there will be cases where an offer with a zero port value 371 will create a corresponding answer with a non-zero port value. 373 5.6. Example 375 m=application 54111 SCTP/DTLS 54111 376 a=sctpmap:54111 webrtc-datachannel 378 Figure 1: SDP Media Description for a CLUE Data Channel 380 6. Security Considerations 382 This specification does not introduce new security considerations, in 383 addition to those defined in [ref-to-data-channel] and [ref-to-data- 384 protocol]. Security considerations associated with the CLUE protocol 385 are defined in [ref-to-clue-protocol]. 387 7. IANA Considerations 389 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 390 document.] 392 8. Acknowledgments 394 Thanks to Paul Kyzivat and Christian Groves for comments on the 395 document. 397 9. Change Log 399 [RFC EDITOR NOTE: Please remove this section when publishing] 401 Changes from draft-holmberg-clue-datachannel-03 403 o Procedures updated, based on WG agreement (IETF#89) to use DCEP 404 for the CLUE data channel. 405 o Procedures updated, based on WG agreement (IETF#89) that SDP 406 Offerer is responsible for sending DCEP DATA_CHANNEL_OPEN. 407 o Editorial changes, and alignments caused by changes in referenced 408 specifications. 410 Changes from draft-holmberg-clue-datachannel-02 412 o PPID value for CLUE messages added 413 o References updated 415 Changes from draft-holmberg-clue-datachannel-01 417 o More text added 419 Changes from draft-holmberg-clue-datachannel-00 421 o Editorial corrections based on comments from Paul K 423 10. References 425 10.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 431 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 432 Zhang, L., and V. Paxson, "Stream Control Transmission 433 Protocol", RFC 2960, October 2000. 435 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 436 A., Peterson, J., Sparks, R., Handley, M., and E. 437 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 438 June 2002. 440 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 441 with Session Description Protocol (SDP)", RFC 3264, June 442 2002. 444 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 445 4960, September 2007. 447 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 448 Kozuka, "Stream Control Transmission Protocol (SCTP) 449 Dynamic Address Reconfiguration", RFC 5061, September 450 2007. 452 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 453 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 454 6525, February 2012. 456 [I-D.presta-clue-protocol] 457 Presta, R. and S. Romano, "CLUE protocol", draft-presta- 458 clue-protocol-03.txt (work in progress), November 2013. 460 [I-D.ietf-tsvwg-sctp-dtls-encaps] 461 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 462 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 463 dtls-encaps-02.txt (work in progress), October 2013. 465 [I-D.ietf-rtcweb-data-channel] 466 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 467 Channels", draft-ietf-rtcweb-data-channel-07.txt (work in 468 progress), February 2014. 470 [I-D.ietf-rtcweb-data-protocol] 471 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 472 Establishment Protocol", draft-ietf-rtcweb-data- 473 protocol-03.txt (work in progress), February 2014. 475 [I-D.stewart-tsvwg-sctp-ndata] 476 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 477 New Data Chunk for Stream Control Transmission Protocol", 478 draft-stewart-tsvwg-sctp-ndata-03.txt (work in progress), 479 October 2013. 481 [I-D.tuexen-tsvwg-sctp-prpolicies] 482 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 483 "Additional Policies for the Partial Delivery Extension of 484 the Stream Control Transmission Protocol", draft-tuexen- 485 tsvwg-sctp-prpolicies-03.txt (work in progress), October 486 2013. 488 10.2. Informative References 490 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 491 Conrad, "Stream Control Transmission Protocol (SCTP) 492 Partial Reliability Extension", RFC 3758, May 2004. 494 [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 495 Ejzak, R. and J. Marcon, "SDP-based WebRTC data channel 496 negotiation", draft-ejzak-dispatch-webrtc-data-channel- 497 sdpneg-00.txt (work in progress), October 2013. 499 Author's Address 501 Christer Holmberg 502 Ericsson 503 Hirsalantie 11 504 Jorvas 02420 505 Finland 507 Email: christer.holmberg@ericsson.com