idnits 2.17.1 draft-marcon-rtcweb-data-channel-management-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 19, 2013) is 4084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'WSAPI' is mentioned on line 434, but not defined == Unused Reference: 'ITU.T140.1998' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'WebRtcAPI' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'WebSocketAPI' is defined on line 634, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-02 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-02 == Outdated reference: A later version (-04) exists of draft-jesup-rtcweb-data-protocol-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWeb J. Marcon 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational February 19, 2013 5 Expires: August 23, 2013 7 RTCWeb data channel management 8 draft-marcon-rtcweb-data-channel-management-00 10 Abstract 12 The Real-Time Communication in WEB-browsers (RTCWeb) working group is 13 charged to provide protocols to support direct interactive rich 14 communication using audio, video, and data between two peers' web- 15 browsers. For the support of data communication, the RTCWeb working 16 group has in particular defined the concept of bi-directional data 17 channels over SCTP. How to transport application messages on these 18 data channels seems straightforward (i.e. they can be carried as SCTP 19 user messages), however it is yet to be decided how to establish and 20 manage these data channels. This document specifies a method for 21 this, which relies first on a lightweight and scalable out-of-band 22 negotiation of data channel configurations (within the SDP offer/ 23 answer exchange) and second on the signaling of the configuration in 24 use in the SCTP user message itself. Once these configurations are 25 negotiated, further creations of data channels can occur purely in- 26 band by simply sending user messages, which avoids to define a new 27 in-band data channel protocol. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 23, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Data channel configuration and message properties . . . . . . 6 68 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 7 70 6.2. Opening a data channel out-of-band . . . . . . . . . . . . 8 71 6.3. Opening a data channel in-band . . . . . . . . . . . . . . 9 72 6.4. Closing a data channel . . . . . . . . . . . . . . . . . . 10 73 6.5. Sending and Receiving Data . . . . . . . . . . . . . . . . 10 74 6.6. Out-of-band signaling . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 [I-D.ietf-rtcweb-data-channel] provides use cases and requirements 86 for the definition of RTCWeb data channels, and outlines how the 87 Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated 88 within Datagram Transport Layer Security (DTLS) [RFC6347] can be used 89 for this purpose. While some of these requirements easily map to 90 existing capabilities of the SCTP protocol and extensions (e.g. 91 application messages can be carried as SCTP user messages), SCTP and 92 existing SCTP extensions do not natively support the following 93 requirements: 95 o data channel bidirectionality (this can be achieved by pairing one 96 SCTP outbound stream and one SCTP inbound stream) 98 o data channel priority 100 o partial reliability of delivery, based on a maximum number of 101 retransmissions 103 o general data channel setup 105 For setting up the SCTP association, the in-band SCTP association 106 initialization is assisted out-of-band by JSEP [I-D.ietf-rtcweb-jsep] 107 and the SDP Offer/Answer model [RFC3264]. For setting up each data 108 channel, several approaches can be considered: 110 1. a purely in-band data channel setup - such a protocol does not 111 exist today. 113 2. a hybrid in-band / out-of-band data channel setup, where the in- 114 band signaling relies on a new protocol defined on top of SCTP 115 user messages. The proposal [I-D.jesup-rtcweb-data-protocol] 116 follows this approach. 118 3. an out-of-band negotiation of data channel configurations, 119 minimally assisted by some lightweight in-band signaling allowing 120 further in-band creations of data channels. 122 This document describes the latter approach, preferred by the author 123 for the following reasons: 125 o Minimal need for SDP renegotiation: the initial offer/answer for 126 establishing the SCTP association is often enough. 128 o Scalability of the SDP signaling: typically it is as light as a 129 couple of attribute lines regardless of the number of data 130 channels created in the session. 132 o Potential interoperability with other systems, due to the use of 133 out-of-band signaling. 135 o Ability to create data channels purely in-band, once the data 136 channel configurations are negotiated 138 o No need for a new in-band data channel control protocol. 140 o Speed: No control message overhead for the in-band creation of 141 data channels: sending user messages automatically creates new 142 data channels. 144 o Simplicity of implementation. 146 As a result, the proposal can easily cope with strenuous data 147 transmission scenarios, like: 149 o The transfer of a high number of files, eventually in parallel. 151 o The fast opening and closing of one data channel. 153 2. Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. Terminology 161 This document uses the following terms: 163 Agent: As defined in [RFC3264], an agent is the protocol 164 implementation involved in the offer/answer exchange. There are 165 two agents involved in an offer/answer exchange. 167 Configuration: a fixed set of data channel parameters, 168 constraining the configuration of some or all the data channels 169 created on top of a given SCTP association. 171 Data channel: A bidirectional channel consisting of paired SCTP 172 outbound and inbound streams. 174 In-band: transmission through the peer-to-peer SCTP association. 176 Out-of-band: transmission through the RTCWeb signaling path, using 177 JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer model 178 [RFC3264]. 180 Peer: From the perspective of one of the agents in a session, its 181 peer is the other agent. Specifically, from the perspective of 182 the SDP offerer, the peer is the SDP answerer. From the 183 perspective of the SDP answerer, the peer is the SDP offerer. 185 Stream: A unidirectional stream of an SCTP association. It is 186 uniquely identified by a stream identifier. 188 4. Overview 190 This section provides an overview of the approach detailed in this 191 document. 193 A data channel configuration is an identified fixed set of data 194 channel parameters potentially applicable to some or all of the data 195 channels created during the session. These parameters include: order 196 of delivery, reliability of delivery, subprotocol. 198 Configurations are uniquely identified throughout the session, and 199 negotatied out-of-band between the endpoints. The configuration 200 concept is transparent to the application, which sets up and handles 201 each data channel individually. Whenever the application creates a 202 new data channel, the browser internally checks if the passed set of 203 parameters strictly matches an existing configuration, and if not 204 generates a new configuration identifier for this set. In the latter 205 case only does the browser trigger the application for an SDP 206 renegotiation. 208 In the SDP offer, the offerer associates to the m=application SDP 209 line that defines the SCTP association one attribute line per data 210 channel configuration. 212 For each data channel configuration in the offer that is accepted by 213 the answerer, the answerer echoes in the answer the configurations 214 supported and accepted. Once the offerer receives the answer and (in 215 case of an initial offer) the SCTP initialization is complete, each 216 data channel locally created using one of the accepted configurations 217 is signaled to the application as open for transmission. 219 Each created data channel is bound to to one negotiated 220 configuration. 222 By convention, the inbound and outbound streams of a data channel 223 have the same SCTP stream number. This stream number is selected by 224 the first endpoint sending a user message on this channel. Till this 225 happens, an open data channel has no assigned stream number. 227 Data channel messages are sent as SCTP user messages, preceded in the 228 DATA chunk User Data field by two bytes specifying data channel 229 configuration identifier as well as the message data framing type 230 (textual or binary). 232 A user message received on a stream number not assigned to any data 233 channel automatically opens a data channel, set up according to the 234 configuration signaled in the user message. 236 Closing a data channel is done in-band by resetting the Stream 237 Sequence Number (SSN) of the related SCTP inbound and outbound 238 streams, as defined in [RFC6525]. 240 This proposal requires the registration of one SCTP Payload Protocol 241 Identifier. 243 5. Data channel configuration and message properties 245 For the proposal in this document, a data channel configuration is 246 characterized by the following properties: 248 o configuration identifier, a 12-bit integer unique across all the 249 data channel configurations managed during the lifetime of an SCTP 250 association. 252 o ownership: the configuration is owned by the endpoint which 253 originated the very first offer that included this configuration, 254 for a given SCTP association. 256 o reliability of delivery: full reliability (as per [RFC4960]) or 257 partial reliability with max transmission lifetime (as per 258 [RFC3758]) or partial reliability with max number of 259 retransmissions. 261 o order of delivery: ordered or unordered 263 o subprotocol identifier 265 o subprotocol setup data, if applicable 267 For the proposal in this document, a data channel is characterized 268 from an endpoint viewpoint by the following properties: 270 o Configuration identifier. It can bind multiple data channels at a 271 time. 273 o Label: local human-readable description of the data channel. 275 o Data channel priority 277 o SCTP stream number: common to the SCTP outbound stream and inbound 278 stream composing the data channnel. 280 o state, which can have the following values: 282 * Connecting: data channel opened locally, and awaiting opening 283 acknowledgment by the peer. 285 * Open: data channel available for bidirectional data 286 transmission. 288 * Closing: data channel closed locally, and awaiting closing 289 acknowledgment by the peer. 291 * Closed: data channel closed by the agent, and acknowledged as 292 closed by the peer. 294 A message sent over a data channel inherits from the transmission 295 properties configured to this data channel: reliability and order of 296 delivery. In addition, the message is characterized by the following 297 message-specific property: 299 o transport format encoding: text or binary. 301 Note that for API simplification purpose, reliability, order of 302 delivery and payload protocol identifier are not configurable per 303 user message, but per data channel only. 305 The payload protocol identifier (PPID) field present in SCTP DATA 306 chunks is used to signal the data framing described in this document. 307 This value is to be obtained from the SCTP Payload Protocol 308 Identifiers registry managed by IANA. 310 6. Procedures 312 6.1. Initialization 314 The PeerConnection and underlying SCTP association are initialized 315 with N data channels, all in Closed state, and with respective 316 outbound and inbound stream numbers ranging from 0 to N-1. The 317 number N can be specified by the application or else defaults to 16. 319 6.2. Opening a data channel out-of-band 321 An application creating a data channel providing some data channel 322 parameters to the agent's browser. If the subset of these parameters 323 composing a data channel configuration does not strictly match an 324 existing configuration, the browser assigns a new configuration 325 identifier to this subset, and binds it to the data channel. The 326 configuration identifier is generated incrementally, starting from 327 zero for each SCTP association. Identifiers of configurations 328 rejected by the answerer must never be used again. 330 In addition, if the application requests the creation: 332 o at a time where the endpoint is in a stable state with an SCTP 333 association already set up, and if the match of configuration is 334 successful, the browser then sets the data channel state to Open. 336 o Otherwise the browser sets the data channel state to Connecting. 337 Moreover, unless the endpoint is in an init state and createOffer 338 has not yet been called, the browser notifies to the application 339 the need for an SDP renegotiation. 341 The created data channel has no assigned SCTP stream number yet. At 342 this stage though the user agent can anticipate a shortage of 343 available SCTP streams and send in-band the request to increase the 344 number of SCTP streams. 346 The new offer (if any) contains one 'm-line' for the SCTP assocation, 347 and one attribute line per data channel configuration. This list of 348 configurations must include the new configurations as well as all the 349 configurations successfully negotiated in previous offer/answer 350 exchanges for this SCTP association. 352 The peer's browser receiving the offer does the following: 354 1. for the data channels that are in Open state but which are bound 355 to a configuration no longer present in the offer, change their 356 state to Closed 358 2. for each newly offered configuration, the peer's browser then 359 informs the application of a new offered data channel along with 360 the configuration specifics. The application can accept this 361 data channel (intended: configuration) by creating a new data 362 channel using the configuration parameters. Not doing so will 363 mean to reject the configuration in the answer. 365 Note: for each new configuration, the offerer expectedly creates 366 one data channel or more, whereas the answerer creates one data 367 channel only. How the final data channel pairing (and SCTP stream 368 number assignment) is resolved is further explained in this 369 document. 371 Note: the answerer can only reject new configurations, 372 configurations previously negotiated cannot be removed from the 373 configuration list associated with the SCTP association. 375 The agent's browser receiving the answer does the following: 377 1. for the data channels not in Closed state and bound to a 378 configuration no longer listed in the answer, change their state 379 to Closed. 381 2. for each newly offered data channel configuration accepted by the 382 answerer, change the state of any data channel bound to this 383 configuration from Connecting to Open. 385 6.3. Opening a data channel in-band 387 Each user message sent in a data channel includes the identifier of 388 the configuration which this data channel is bound to. This 389 signaling allows to enable or speed up the opening of new data 390 channels in-band: 392 o Case A: In a stable state, the local creation of a data channel 393 with parameters mapping to a negotiated configuration creates the 394 data channel in Open state immediately, and does not signal this 395 to the peer. Some time later, when the application sends its 396 first message on this data channel: 398 1. the agent's browser selects for the lifetime of the data 399 channel an SCTP outbound stream number not used by any 400 channel. 402 2. it then sends the user message over this SCTP stream. 404 3. the peer's browser SACKnowledges the user message, using an 405 SCTP stream of same stream number (expectedly unused). It 406 then notifies the peer's application of the data channel 407 opening. 409 o Case B: Once the answerer has accepted a new offerer's 410 configuration, and has subsequently opened a data channel bound to 411 this configuration, the answerer's application may choose to send 412 user messages on this channel immediately. The offerer receiving 413 this message should: 415 1. route this message to one of the Connecting-state data 416 channels bound to the same configuration. 418 2. change its state to Open, and sets its SCTP outbound stream 419 number (expectedly unused) to the SCTP inbound stream number 420 of the message. 422 3. delivers the message to the application. 424 6.4. Closing a data channel 426 When the application requests to close a data channel, the agent's 427 browser initiates an in-band Stream Sequence Number (SSN) reset of 428 the related SCTP inbound and outbound streams. These streams are 429 then available for further reuse. 431 6.5. Sending and Receiving Data 433 To expose to upper layers an API similar to the Web Socket API 434 [WSAPI], the agent's browser needs to specify to the peer's browser 435 the framing type of each data channel message, amongst binary or text 436 (UTF-8). 438 In addition, each user message needs to carry the identifier of the 439 configuration which the data channel is bound to. 441 For the sending of a user message over an opened data channel, the 442 agent's browser: 444 1. converts the message data from UTF-16 to UTF-8 if provided by the 445 application as a DOMString. 447 2. sets in the DATA chunk the Unordered bit, Payload Protocol 448 Identifier and Stream Number as per data channel configuration. 450 3. constructs the User Data field as the framing type byte(s) 451 followed by the (converted) message data 453 0 1 2 3 454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 455 +------------------------+------+-------------------------------+ 456 | Config ID | Type | Payload Data | 457 +------------------------+------+ - - - - - - - - - - - - - - - + 458 : Payload Data continued ... : 459 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 460 | Payload Data continued ... | 461 +---------------------------------------------------------------+ 463 RTCWeb data framing 465 Config ID : 12 bits 467 Identifies a data channel configuration negotiated out of band 468 between the two endpoints. 470 Note: to be considered if the Config ID should be included in 471 all user messages. 473 Type : 4 bits 475 Defines the data framing type of "Payload data". If an unknown 476 type is received, the receiving endpoint must reject the user 477 message. The following values are defined: 479 * x0 denotes a binary frame 481 * x1 denotes a UTF-8 encoded text frame 483 * x2-xFFF are reserved for further use 485 An agent's browser receiving a user message on a data channel behaves 486 as follows: 488 o If the configuration identifier in the message does not map to any 489 negotiated configuration, or if the data channel (identified by 490 the message stream number) is in Closing or Connecting state, 491 reject (or discard?) the message. 493 o Otherwise (i.e. supported configuration identifier and Open 494 state): 496 If the endpoint has just sent the very first user message on 497 this data channel and has not yet received the SACK, it means 498 that both endpoints attempt to dynamically create a data 499 channel by the sending of a user message. In this case, if the 500 endpoint has ownership of the signaled configuration, the 501 browser must discard (reject?) the message. 503 Note: another way of avoiding this conflict is to state by 504 convention that the endpoint which initiated the offer for 505 the SCTP association establishment owns all the even stream 506 numbers, while the other endpoint owns all the odd stream 507 numbers. 509 Otherwise deliver the message. 511 o Otherwise (i.e. supported configuration identifier and Closed 512 state): 514 If a Connecting-state data channel exists with no assigned 515 stream number, open it with a stream number set to the message 516 stream number. 518 If not, open a new data channel with a stream number set to the 519 message stream number 521 Finally, deliver the message. 523 6.6. Out-of-band signaling 525 To signal the data channel configurations intended for use during the 526 lifetime of an SCTP association, the agent completes the SDP 527 section of the m=application SDP line defined for the SCTP 528 association. For each data channel configuration previously 529 negotiated or newly added at the time of offer generation, the 530 agent's browser: 532 o must specify: configuration identifier. 534 o may specify: order of delivery, reliability of delivery, 535 subprotocol, subprotocol configuration data. 537 As an example in the offer (line split for readability): 539 m=application 54111 DTLS/SCTP 5000 540 a=sctpmap:5000 webrtc-DataChannel 16 541 a=sctp-protocol:5000 config=1;label="channel 1";subprotocol="chat"; 542 a=sctp-protocol:5000 config=2;label="channel 2"; 543 subprotocol="file transfer";max_retr=3 545 data channel configuration setup in SDP offer 547 An in the returned answer (line split for readability): 549 m=application 54111 DTLS/SCTP 5000 550 a=sctpmap:5000 webrtc-DataChannel 16 551 a=sctp-protocol:5000 config=2;label="channel 2"; 552 subprotocol="file transfer";max_retr=3 554 data channel configuration setup in SDP answer 556 In reply to this offer, the peer constructs in the answer the data 557 channel configuration list of the SCTP association as follows: 559 o drop any unwanted or unsupported data channel configuration 561 o echo the other configurations, and preserve the following 562 properties at least: configuration identifier, subprotocol (if 563 any). Specifies also the peer-specific properties (subprotocol 564 setup data). 566 This may need to be specified via MMUSIC. 568 7. Security Considerations 570 To be completed. 572 8. IANA Considerations 574 To be completed. 576 9. Acknowledgments 578 The authors wish to thank Richard Ejzak, ... for their invaluable 579 comments. 581 10. References 583 10.1. Normative References 585 [I-D.ietf-rtcweb-jsep] 586 Uberti, J. and C. Jennings, "Javascript Session 587 Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work 588 in progress), October 2012. 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 594 Conrad, "Stream Control Transmission Protocol (SCTP) 595 Partial Reliability Extension", RFC 3758, May 2004. 597 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 598 RFC 4960, September 2007. 600 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 601 Security Version 1.2", RFC 6347, January 2012. 603 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 604 Transmission Protocol (SCTP) Stream Reconfiguration", 605 RFC 6525, February 2012. 607 10.2. Informative References 609 [I-D.ietf-rtcweb-data-channel] 610 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram 611 Connection", draft-ietf-rtcweb-data-channel-02 (work in 612 progress), October 2012. 614 [I-D.jesup-rtcweb-data-protocol] 615 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 616 Protocol", draft-jesup-rtcweb-data-protocol-03 (work in 617 progress), September 2012. 619 [ITU.T140.1998] 620 "Protocol for Multimedia Application Text Conversation", 621 ITU-T Recommendation T.140, February 1998. 623 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 624 with Session Description Protocol (SDP)", RFC 3264, 625 June 2002. 627 [WebRtcAPI] 628 Bergkvist, A., Burnett, D., Narayanan, A., and C. 629 Jennings, "WebRTC 1.0: Real-time Communication Between 630 Browsers", World Wide Web Consortium WD WD-webrtc- 631 20120821, August 2012, 632 . 634 [WebSocketAPI] 635 Hickson, I., "The WebSocket API", World Wide Web 636 Consortium LastCall WD-websockets-20120809, August 2012, 637 . 639 Author's Address 641 Jerome Marcon 642 Alcatel-Lucent 643 Route de Villejust 644 Nozay 91620 645 France 647 Email: jerome.marcon@alcatel-lucent.com