idnits 2.17.1 draft-ietf-clue-datachannel-07.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 (January 30, 2015) is 3373 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 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') == Outdated reference: A later version (-15) exists of draft-ietf-clue-signaling-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-signaling (ref. 'I-D.ietf-clue-signaling') == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-08 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-12 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-sctp-prpolicies-06 == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-00 Summary: 4 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 January 30, 2015 5 Expires: August 3, 2015 7 CLUE Protocol Data Channel 8 draft-ietf-clue-datachannel-07 10 Abstract 12 This document defines how to use the WebRTC Data Channel mechanism in 13 order to realize a data channel, referred to as a CLUE data channel, 14 for transporting CLUE protocol messages between two CLUE entities. 16 The document defines how to describe the SCTPoDTLS association used 17 to realize the CLUE data channel using the Session Description 18 Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data 19 channel negotiation mechanism for establishing a CLUE data channel. 21 Details and procedures associated with the CLUE protocol, and the SDP 22 Offer/Answer procedures for negotiating usage of a CLUE data channel, 23 are outside 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 August 3, 2015. 42 Copyright Notice 44 Copyright (c) 2015 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. SDP Considerations . . . . . . . . . . . . . . . . . . . 4 64 3.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2.2. SDP dcpmap Attribute . . . . . . . . . . . . . . . . 5 66 3.2.3. SDP dcsa Attribute . . . . . . . . . . . . . . . . . 6 67 3.2.4. Example . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. SCTP Considerations . . . . . . . . . . . . . . . . . . . 6 69 3.3.1. SCTP Payload Protocol Identifier (PPID) . . . . . . . 6 70 3.3.2. Reliability . . . . . . . . . . . . . . . . . . . . . 6 71 3.3.3. Order . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.4. Stream Reset . . . . . . . . . . . . . . . . . . . . 7 73 3.3.5. SCTP Multihoming . . . . . . . . . . . . . . . . . . 7 74 3.3.6. Close CLUE Data Channel . . . . . . . . . . . . . . . 7 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. New WebRTC Data Channel Protocol Value . . . . . . . . . 7 78 5.2. New SDP dcmap attribute subprotocol value . . . . . . . . 8 79 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 8.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This document defines how to use the WebRTC Data Channel mechanism 89 [I-D.ietf-rtcweb-data-channel] in order to realize a data channel, 90 referred to as a CLUE data channel, for transporting CLUE protocol 91 messages between two CLUE entities. 93 The document defines how to describe the SCTPoDTLS association 94 [I-D.ietf-tsvwg-sctp-dtls-encaps] used to realize the CLUE data 95 channel using the Session Description Protocol (SDP) [RFC4566], and 96 defines usage of the SDP-based "SCTP over DTLS" data channel 97 negotiation mechanism [I-D.ejzak-mmusic-data-channel-sdpneg]. This 98 includes SCTP considerations specific to a CLUE data channel, the SDP 99 Media Description (m- line) values, and usage of SDP attributes 100 specific to a CLUE data channel. 102 Details and procedures associated with the CLUE protocol, and the SDP 103 Offer/Answer [RFC3264] procedures for negotiating usage of a CLUE 104 data channel, are outside the scope of this document. 106 NOTE: The usage of the Data Channel Establishment Protocol (DCEP) 107 [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel 108 is outside 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 SCTPoDTLS association refers to an SCTP association carried over an 118 DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]. 120 WebRTC Data Channel refers to a SCTPoDTLS association 121 [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media 122 data between two entities, according to the procedures in 123 [I-D.ietf-rtcweb-data-channel]. 125 CLUE data channel refers to a WebRTC Data Channel 126 [I-D.ietf-rtcweb-data-channel] realization, with a specific set of 127 SCTP characteristics, with the purpose of transporting CLUE protocol 128 [I-D.ietf-clue-protocol] messages between two CLUE entities. 130 CLUE entity refers to a SIP User Agent (UA) [RFC3261] that supports 131 the CLUE data channel and the CLUE protocol. 133 CLUE session refers to a SIP session [RFC3261] between to SIP UAs, 134 where a CLUE data channel, associated with the SIP session, has been 135 established between the SIP UAs. 137 [RFC4960] defines an SCTP stream as a unidirectional logical channel 138 established from one to another associated SCTP endpoint, within 139 which all user messages are delivered in sequence except for those 140 submitted to the unordered delivery service. 142 [RFC4960] defines an SCTP identifier as a unsigned integer, which 143 identifies a SCTP stream. 145 3. CLUE Data Channel 147 3.1. General 149 This section describes the realization of a CLUE Data Channel. This 150 includes a set of SCTP characteristics specific to a CLUE Data 151 Channel, the values of the m- line describing the SCTPoDTLS 152 association associated with the WEBRTC Data Channel, and the usage of 153 the SDP-based "SCTP over DTLS" data channel negotiation mechanism for 154 creating the CLUE Data Channel. 156 As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams 157 realizing a WebRTC Data Channel must be associated with the same SCTP 158 association. In addition, both SCTP streams realizing the WebRTC 159 Data Channel must use the same SCTP stream identifier value. These 160 rules also apply to a CLUE Data Channel. 162 Within a given CLUE session, a CLUE entity MUST use a single CLUE 163 Data Channel for transport of all CLUE messages towards its peer. 165 3.2. SDP Considerations 167 3.2.1. General 169 This section defines how to construct the SDP Media Description (m- 170 line) for describing the SCTPoDTLS association used to realize a 171 WebRTC Data Channel. The section also defines how to construct the 172 SDP dcmap attribute, used with the SDP-based "SCTP over DTLS" data 173 channel negotiation mechanism for establishing a CLUE Data Channel on 174 the SCTPoDTLS association. 176 NOTE: Other protocols than SDP for negotiating usage of a SCTPoDTLS 177 association for realizing a WebRTC Data Channel are outside the scope 178 of this specification. 180 [I-D.ietf-clue-signaling] describes the SDP Offer/Answer procedures 181 for negotiating a CLUE session, including the CLUE controlled media 182 streams and the CLUE Data Channel. 184 3.2.1.1. SDP Media Description Fields 186 As defined in [I-D.ietf-mmusic-sctp-sdp], the field values of an m- 187 line describing an SCTPoDTLS association are set as following: 189 +---------------+--------------+-----------------+------------------+ 190 | media | port | proto | fmt | 191 +---------------+--------------+-----------------+------------------+ 192 | "application" | UDP port | "UDP/DTLS/SCTP" | application | 193 | | value | | usage | 194 | "application" | TCP port | "TCP/DTLS/SCTP" | application | 195 | | value | | usage | 196 +---------------+--------------+-----------------+------------------+ 198 Table 1: SDP "proto" field values 200 As defined in [I-D.ietf-mmusic-sctp-sdp], when the SCTPoDTLS 201 association is used to realize a WebRTC data channel, the value of 202 the application usage part is 'webrtc-datachannel'. 204 3.2.1.2. SDP sctp-port Attribute 206 As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute 207 value is set to the SCTP port of the SCTPoDTLS association. 209 3.2.2. SDP dcpmap Attribute 211 When the SDP-based "SCTP over DTLS" data channel negotiation 212 mechanism is used to establish a CLUE data channel, the values of the 213 SDP dcmap attribute [I-D.ejzak-mmusic-data-channel-sdpneg], 214 associated with the m- line describing the SCTPoDTLS association used 215 to realize the WebRTC Data Channel, are set as following: 217 +----------+------------+------------+--------+----------+----------+ 218 | stream- | subprotoco | label | ordere | max-retr | max-time | 219 | id | l | | d | | | 220 +----------+------------+------------+--------+----------+----------+ 221 | Value of | "CLUE" | Applicatio | N/A | N/A | N/A | 222 | the SCTP | | n specific | | | | 223 | stream | | | | | | 224 | used to | | | | | | 225 | realize | | | | | | 226 | the CLUE | | | | | | 227 | data | | | | | | 228 | channel | | | | | | 229 +----------+------------+------------+--------+----------+----------+ 231 Table 2: SDP dcmap attribute values 233 3.2.3. SDP dcsa Attribute 235 The SDP dcsa attribute [I-D.ejzak-mmusic-data-channel-sdpneg] is not 236 used when establishing a CLUE data channel. 238 3.2.4. Example 240 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 241 a=sctp-port: 5000 242 a=dcmap:2 subprotocol="CLUE" 244 Figure 1: SDP Media Description for a CLUE Data Channel 246 3.3. SCTP Considerations 248 3.3.1. SCTP Payload Protocol Identifier (PPID) 250 A CLUE entity MUST use the PPID value 51 when sending a CLUE message 251 on a CLUE data channel. 253 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 254 51 indicates that the SCTP message contains data encoded in a UTF-8 255 format. The PPID value 51 does not indicate what application 256 protocol the SCTP message is associated with, only the format in 257 which the data is encoded. 259 +----------+------------+ 260 | Protocol | PPID Value | 261 +----------+------------+ 262 | CLUE | 51 | 263 +----------+------------+ 265 Table 3: CLUE Data Channel PPID Values 267 3.3.2. Reliability 269 The usage of SCTP for the CLUE Data Channel ensures reliable 270 transport of CLUE protocol [I-D.ietf-clue-protocol] messages. 272 A CLUE entity MUST NOT use the partial reliability and limited 273 retransmission extensions defined in [RFC3758]. 275 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 276 partial reliability extension defined in [RFC3758]. This is not 277 needed for a CLUE Data Channel, as messages are required to always be 278 sent reliably. [I-D.ietf-rtcweb-data-channel] also mandates support 279 of the limited retransmission policy defined in 280 [I-D.ietf-tsvwg-sctp-prpolicies]. 282 3.3.3. Order 284 A CLUE entity MUST use the ordered delivery SCTP service, as 285 described in section 6.6 of [RFC4960]. 287 3.3.4. Stream Reset 289 A CLUE entity MUST support the stream reset extension defined in 290 [RFC6525]. 292 The dynamic address reconfiguration extension defined in [RFC5061] 293 MUST be used to signal the support of the stream reset extension 294 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 296 3.3.5. SCTP Multihoming 298 SCTP multi-homing is not supported for SCTPoDTLS associations, and 299 can therefor not be used for a CLUE data channel. 301 3.3.6. Close CLUE Data Channel 303 As described in [I-D.ietf-rtcweb-data-protocol], in order to close a 304 data channel, a SCTP reset message [RFC6525] is sent, in order to 305 close the SCTP stream associated with the data channel. The 306 SCTPoDTLS association, and other data channels established on the 307 same association, are not affected by the SCTP reset message. 309 4. Security Considerations 311 This specification does not introduce new security considerations, in 312 addition to those defined in [I-D.ietf-rtcweb-data-channel] and 313 [I-D.ietf-rtcweb-data-protocol]. Security considerations associated 314 with the CLUE protocol are defined in [I-D.ietf-clue-protocol]. 316 5. IANA Considerations 318 5.1. New WebRTC Data Channel Protocol Value 320 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 321 document.] 323 This document adds the 'CLUE' value to the "WebSocket Subprotocol 324 Name Registry" as follows: 326 Subprotocl Identifier: CLUE 327 Subprotocol Common Name: CLUE 328 Subprotocol Definition: RFC-XXXX 330 5.2. New SDP dcmap attribute subprotocol value 332 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 333 document.] 335 OPEN ISSUE: [I-D.ejzak-mmusic-data-channel-sdpneg] has not yet 336 created a registry for new subprotocol values. 338 6. Acknowledgments 340 Thanks to Paul Kyzivat and Christian Groves for comments on the 341 document. 343 7. Change Log 345 [RFC EDITOR NOTE: Please remove this section when publishing] 347 Changes from draft-ietf-clue-datachannel-06 349 o Usage of DCEP removed. 351 Changes from draft-ietf-clue-datachannel-05 353 o "DTLS/SCTP" split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". 354 o Removed note regarding optionality of including the SDP sctp-port 355 attribute. 356 o Added defintion of 'SCTPoDTLS association' to the Conventions. 357 o Reference to RFC 4566 (SDP) added. 359 Changes from draft-ietf-clue-datachannel-04 361 o Defines DCEP and external SDP negotiation as two separate 362 mechanisms for negotiating a CLUE data channel. 363 o Updates based on technical changes in referenced specifications. 364 o Reference to draft-ietf-mmusic-sctp-sdp added. 366 Changes from draft-ietf-clue-datachannel-03 368 o IANA considerations added. 369 o Editorial changes based on comments from Christian Groves. 371 Changes from draft-ietf-clue-datachannel-02 372 o SDP m- line example fixed. 373 o OPEN ISSUE #1 closed. 374 o - It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel- 375 sdpneg, as it was adopted as a WG item in MMUSIC. 376 o - Details for draft-ejzak-mmusic-data-channel-sdpneg usage added. 377 o SDP Offer/Answer procedures removed, as they will be defined in 378 the CLUE protocol draft. 379 o References updated. 381 Changes from draft-ietf-clue-datachannel-01 383 o Support of interleaving "MUST"->"SHOULD". 384 o Example updated. 385 o Reference update. 387 Changes from draft-ietf-clue-datachannel-00 389 o SDP Offer/Answer procedures structures according to RFC 3264. 390 o Reference update. 392 Changes from draft-holmberg-clue-datachannel-04 394 o Draft submitted as draft-ietf-clue-data-channel-00. 395 o Editorial nits fixed. 396 o Changes based on comments from Paul Kyzivat (http://www.ietf.org/ 397 mail-archive/web/clue/current/msg03559.html). 398 o - Proto value fixed. 399 o - Explicit text that the partial reliability and limited 400 retransmission policies MUST NOT be used. 401 o - Added open issue on whether the DCEP 'protocol' field value for 402 CLUE should contain a version number. 403 o - Removed paragraph saying that an offerer must not insert more 404 than one m- line describing an SCTPoDTLS association to be used to 405 realize a CLUE Data Channel, as the draft already states that only 406 one CLUE Data Channel per CLUE session shall be opened. 407 o - Added reference to draft-ietf-rtcweb-data-protocol regarding 408 details on reseting SCTP streams. 409 o - Added text saying that the value of the DCEP 'channel type' MUST 410 be DATA_CHANNEL_RELIABLE. 411 o - Clarified that DCEP must be supported, and used in the absence 412 of another mechanism for opening a CLUE Data Channel. 414 Changes from draft-holmberg-clue-datachannel-03 416 o Procedures updated, based on WG agreement (IETF#89) to use DCEP 417 for the CLUE data channel. 418 o Procedures updated, based on WG agreement (IETF#89) that offerer 419 is responsible for sending DCEP DATA_CHANNEL_OPEN. 421 o Editorial changes, and alignments caused by changes in referenced 422 specifications. 424 Changes from draft-holmberg-clue-datachannel-02 426 o PPID value for CLUE messages added 427 o References updated 429 Changes from draft-holmberg-clue-datachannel-01 431 o More text added 433 Changes from draft-holmberg-clue-datachannel-00 435 o Editorial corrections based on comments from Paul K 437 8. References 439 8.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 445 A., Peterson, J., Sparks, R., Handley, M., and E. 446 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 447 June 2002. 449 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 450 with Session Description Protocol (SDP)", RFC 3264, June 451 2002. 453 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 454 Description Protocol", RFC 4566, July 2006. 456 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 457 4960, September 2007. 459 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 460 Kozuka, "Stream Control Transmission Protocol (SCTP) 461 Dynamic Address Reconfiguration", RFC 5061, September 462 2007. 464 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 465 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 466 6525, February 2012. 468 [I-D.ietf-clue-protocol] 469 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 470 clue-protocol-02.txt (work in progress), October 2014. 472 [I-D.ietf-clue-signaling] 473 Kyzivat, P., Xiao, L., Groves, C., and S. Romano, "CLUE 474 Signaling", draft-ietf-clue-signaling-04.txt (work in 475 progress), October 2014. 477 [I-D.ietf-tsvwg-sctp-dtls-encaps] 478 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 479 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 480 dtls-encaps-08.txt (work in progress), January 2015. 482 [I-D.ietf-mmusic-sctp-sdp] 483 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 484 Control Transmission Protocol (SCTP)-Based Media Transport 485 in the Session Description Protocol (SDP)", draft-ietf- 486 mmusic-sctp-sdp-12.txt (work in progress), January 2015. 488 [I-D.ietf-rtcweb-data-channel] 489 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 490 Channels", draft-ietf-rtcweb-data-channel-13.txt (work in 491 progress), January 2015. 493 [I-D.ietf-tsvwg-sctp-prpolicies] 494 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 495 "Additional Policies for the Partial Reliability Extension 496 of the Stream Control Transmission Protocol", draft-ietf- 497 tsvwg-sctp-prpolicies-06.txt (work in progress), December 498 2014. 500 [I-D.ejzak-mmusic-data-channel-sdpneg] 501 Drage, K., Makaraju, R., Stoetzer-Bradler, J., Ejzak, R., 502 and J. Marcon, "SDP-based "SCTP over DTLS" data channel 503 negotiation", draft-ietf-mmusic-data-channel-sdpneg-00.txt 504 (work in progress), January 2015. 506 8.2. Informative References 508 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 509 Conrad, "Stream Control Transmission Protocol (SCTP) 510 Partial Reliability Extension", RFC 3758, May 2004. 512 [I-D.ietf-rtcweb-data-protocol] 513 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 514 Establishment Protocol", draft-ietf-rtcweb-data-protocol- 515 09.txt (work in progress), January 2015. 517 Author's Address 519 Christer Holmberg 520 Ericsson 521 Hirsalantie 11 522 Jorvas 02420 523 Finland 525 Email: christer.holmberg@ericsson.com