[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
RTCWeb                                                         J. Marcon
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                         February 19, 2013
Expires: August 23, 2013


                     RTCWeb data channel management
             draft-marcon-rtcweb-data-channel-management-00

Abstract

   The Real-Time Communication in WEB-browsers (RTCWeb) working group is
   charged to provide protocols to support direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  For the support of data communication, the RTCWeb working
   group has in particular defined the concept of bi-directional data
   channels over SCTP.  How to transport application messages on these
   data channels seems straightforward (i.e. they can be carried as SCTP
   user messages), however it is yet to be decided how to establish and
   manage these data channels.  This document specifies a method for
   this, which relies first on a lightweight and scalable out-of-band
   negotiation of data channel configurations (within the SDP offer/
   answer exchange) and second on the signaling of the configuration in
   use in the SCTP user message itself.  Once these configurations are
   negotiated, further creations of data channels can occur purely in-
   band by simply sending user messages, which avoids to define a new
   in-band data channel protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 23, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the



Marcon                   Expires August 23, 2013                [Page 1]


Internet-Draft           RTCWeb data management            February 2013


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Data channel configuration and message properties  . . . . . .  6
   6.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Initialization . . . . . . . . . . . . . . . . . . . . . .  7
     6.2.  Opening a data channel out-of-band . . . . . . . . . . . .  8
     6.3.  Opening a data channel in-band . . . . . . . . . . . . . .  9
     6.4.  Closing a data channel . . . . . . . . . . . . . . . . . . 10
     6.5.  Sending and Receiving Data . . . . . . . . . . . . . . . . 10
     6.6.  Out-of-band signaling  . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15

















Marcon                   Expires August 23, 2013                [Page 2]


Internet-Draft           RTCWeb data management            February 2013


1.  Introduction

   [I-D.ietf-rtcweb-data-channel] provides use cases and requirements
   for the definition of RTCWeb data channels, and outlines how the
   Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated
   within Datagram Transport Layer Security (DTLS) [RFC6347] can be used
   for this purpose.  While some of these requirements easily map to
   existing capabilities of the SCTP protocol and extensions (e.g.
   application messages can be carried as SCTP user messages), SCTP and
   existing SCTP extensions do not natively support the following
   requirements:

   o  data channel bidirectionality (this can be achieved by pairing one
      SCTP outbound stream and one SCTP inbound stream)

   o  data channel priority

   o  partial reliability of delivery, based on a maximum number of
      retransmissions

   o  general data channel setup

   For setting up the SCTP association, the in-band SCTP association
   initialization is assisted out-of-band by JSEP [I-D.ietf-rtcweb-jsep]
   and the SDP Offer/Answer model [RFC3264].  For setting up each data
   channel, several approaches can be considered:

   1.  a purely in-band data channel setup - such a protocol does not
       exist today.

   2.  a hybrid in-band / out-of-band data channel setup, where the in-
       band signaling relies on a new protocol defined on top of SCTP
       user messages.  The proposal [I-D.jesup-rtcweb-data-protocol]
       follows this approach.

   3.  an out-of-band negotiation of data channel configurations,
       minimally assisted by some lightweight in-band signaling allowing
       further in-band creations of data channels.

   This document describes the latter approach, preferred by the author
   for the following reasons:

   o  Minimal need for SDP renegotiation: the initial offer/answer for
      establishing the SCTP association is often enough.

   o  Scalability of the SDP signaling: typically it is as light as a
      couple of attribute lines regardless of the number of data
      channels created in the session.



Marcon                   Expires August 23, 2013                [Page 3]


Internet-Draft           RTCWeb data management            February 2013


   o  Potential interoperability with other systems, due to the use of
      out-of-band signaling.

   o  Ability to create data channels purely in-band, once the data
      channel configurations are negotiated

   o  No need for a new in-band data channel control protocol.

   o  Speed: No control message overhead for the in-band creation of
      data channels: sending user messages automatically creates new
      data channels.

   o  Simplicity of implementation.

   As a result, the proposal can easily cope with strenuous data
   transmission scenarios, like:

   o  The transfer of a high number of files, eventually in parallel.

   o  The fast opening and closing of one data channel.


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Terminology

   This document uses the following terms:

      Agent: As defined in [RFC3264], an agent is the protocol
      implementation involved in the offer/answer exchange.  There are
      two agents involved in an offer/answer exchange.

      Configuration: a fixed set of data channel parameters,
      constraining the configuration of some or all the data channels
      created on top of a given SCTP association.

      Data channel: A bidirectional channel consisting of paired SCTP
      outbound and inbound streams.

      In-band: transmission through the peer-to-peer SCTP association.






Marcon                   Expires August 23, 2013                [Page 4]


Internet-Draft           RTCWeb data management            February 2013


      Out-of-band: transmission through the RTCWeb signaling path, using
      JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer model
      [RFC3264].

      Peer: From the perspective of one of the agents in a session, its
      peer is the other agent.  Specifically, from the perspective of
      the SDP offerer, the peer is the SDP answerer.  From the
      perspective of the SDP answerer, the peer is the SDP offerer.

      Stream: A unidirectional stream of an SCTP association.  It is
      uniquely identified by a stream identifier.


4.  Overview

   This section provides an overview of the approach detailed in this
   document.

   A data channel configuration is an identified fixed set of data
   channel parameters potentially applicable to some or all of the data
   channels created during the session.  These parameters include: order
   of delivery, reliability of delivery, subprotocol.

   Configurations are uniquely identified throughout the session, and
   negotatied out-of-band between the endpoints.  The configuration
   concept is transparent to the application, which sets up and handles
   each data channel individually.  Whenever the application creates a
   new data channel, the browser internally checks if the passed set of
   parameters strictly matches an existing configuration, and if not
   generates a new configuration identifier for this set.  In the latter
   case only does the browser trigger the application for an SDP
   renegotiation.

   In the SDP offer, the offerer associates to the m=application SDP
   line that defines the SCTP association one attribute line per data
   channel configuration.

   For each data channel configuration in the offer that is accepted by
   the answerer, the answerer echoes in the answer the configurations
   supported and accepted.  Once the offerer receives the answer and (in
   case of an initial offer) the SCTP initialization is complete, each
   data channel locally created using one of the accepted configurations
   is signaled to the application as open for transmission.

   Each created data channel is bound to to one negotiated
   configuration.

   By convention, the inbound and outbound streams of a data channel



Marcon                   Expires August 23, 2013                [Page 5]


Internet-Draft           RTCWeb data management            February 2013


   have the same SCTP stream number.  This stream number is selected by
   the first endpoint sending a user message on this channel.  Till this
   happens, an open data channel has no assigned stream number.

   Data channel messages are sent as SCTP user messages, preceded in the
   DATA chunk User Data field by two bytes specifying data channel
   configuration identifier as well as the message data framing type
   (textual or binary).

   A user message received on a stream number not assigned to any data
   channel automatically opens a data channel, set up according to the
   configuration signaled in the user message.

   Closing a data channel is done in-band by resetting the Stream
   Sequence Number (SSN) of the related SCTP inbound and outbound
   streams, as defined in [RFC6525].

   This proposal requires the registration of one SCTP Payload Protocol
   Identifier.


5.  Data channel configuration and message properties

   For the proposal in this document, a data channel configuration is
   characterized by the following properties:

   o  configuration identifier, a 12-bit integer unique across all the
      data channel configurations managed during the lifetime of an SCTP
      association.

   o  ownership: the configuration is owned by the endpoint which
      originated the very first offer that included this configuration,
      for a given SCTP association.

   o  reliability of delivery: full reliability (as per [RFC4960]) or
      partial reliability with max transmission lifetime (as per
      [RFC3758]) or partial reliability with max number of
      retransmissions.

   o  order of delivery: ordered or unordered

   o  subprotocol identifier

   o  subprotocol setup data, if applicable

   For the proposal in this document, a data channel is characterized
   from an endpoint viewpoint by the following properties:




Marcon                   Expires August 23, 2013                [Page 6]


Internet-Draft           RTCWeb data management            February 2013


   o  Configuration identifier.  It can bind multiple data channels at a
      time.

   o  Label: local human-readable description of the data channel.

   o  Data channel priority

   o  SCTP stream number: common to the SCTP outbound stream and inbound
      stream composing the data channnel.

   o  state, which can have the following values:

      *  Connecting: data channel opened locally, and awaiting opening
         acknowledgment by the peer.

      *  Open: data channel available for bidirectional data
         transmission.

      *  Closing: data channel closed locally, and awaiting closing
         acknowledgment by the peer.

      *  Closed: data channel closed by the agent, and acknowledged as
         closed by the peer.

   A message sent over a data channel inherits from the transmission
   properties configured to this data channel: reliability and order of
   delivery.  In addition, the message is characterized by the following
   message-specific property:

   o  transport format encoding: text or binary.

   Note that for API simplification purpose, reliability, order of
   delivery and payload protocol identifier are not configurable per
   user message, but per data channel only.

   The payload protocol identifier (PPID) field present in SCTP DATA
   chunks is used to signal the data framing described in this document.
   This value is to be obtained from the SCTP Payload Protocol
   Identifiers registry managed by IANA.


6.  Procedures

6.1.  Initialization

   The PeerConnection and underlying SCTP association are initialized
   with N data channels, all in Closed state, and with respective
   outbound and inbound stream numbers ranging from 0 to N-1.  The



Marcon                   Expires August 23, 2013                [Page 7]


Internet-Draft           RTCWeb data management            February 2013


   number N can be specified by the application or else defaults to 16.

6.2.  Opening a data channel out-of-band

   An application creating a data channel providing some data channel
   parameters to the agent's browser.  If the subset of these parameters
   composing a data channel configuration does not strictly match an
   existing configuration, the browser assigns a new configuration
   identifier to this subset, and binds it to the data channel.  The
   configuration identifier is generated incrementally, starting from
   zero for each SCTP association.  Identifiers of configurations
   rejected by the answerer must never be used again.

   In addition, if the application requests the creation:

   o  at a time where the endpoint is in a stable state with an SCTP
      association already set up, and if the match of configuration is
      successful, the browser then sets the data channel state to Open.

   o  Otherwise the browser sets the data channel state to Connecting.
      Moreover, unless the endpoint is in an init state and createOffer
      has not yet been called, the browser notifies to the application
      the need for an SDP renegotiation.

   The created data channel has no assigned SCTP stream number yet.  At
   this stage though the user agent can anticipate a shortage of
   available SCTP streams and send in-band the request to increase the
   number of SCTP streams.

   The new offer (if any) contains one 'm-line' for the SCTP assocation,
   and one attribute line per data channel configuration.  This list of
   configurations must include the new configurations as well as all the
   configurations successfully negotiated in previous offer/answer
   exchanges for this SCTP association.

   The peer's browser receiving the offer does the following:

   1.  for the data channels that are in Open state but which are bound
       to a configuration no longer present in the offer, change their
       state to Closed

   2.  for each newly offered configuration, the peer's browser then
       informs the application of a new offered data channel along with
       the configuration specifics.  The application can accept this
       data channel (intended: configuration) by creating a new data
       channel using the configuration parameters.  Not doing so will
       mean to reject the configuration in the answer.




Marcon                   Expires August 23, 2013                [Page 8]


Internet-Draft           RTCWeb data management            February 2013


      Note: for each new configuration, the offerer expectedly creates
      one data channel or more, whereas the answerer creates one data
      channel only.  How the final data channel pairing (and SCTP stream
      number assignment) is resolved is further explained in this
      document.

      Note: the answerer can only reject new configurations,
      configurations previously negotiated cannot be removed from the
      configuration list associated with the SCTP association.

   The agent's browser receiving the answer does the following:

   1.  for the data channels not in Closed state and bound to a
       configuration no longer listed in the answer, change their state
       to Closed.

   2.  for each newly offered data channel configuration accepted by the
       answerer, change the state of any data channel bound to this
       configuration from Connecting to Open.

6.3.  Opening a data channel in-band

   Each user message sent in a data channel includes the identifier of
   the configuration which this data channel is bound to.  This
   signaling allows to enable or speed up the opening of new data
   channels in-band:

   o  Case A: In a stable state, the local creation of a data channel
      with parameters mapping to a negotiated configuration creates the
      data channel in Open state immediately, and does not signal this
      to the peer.  Some time later, when the application sends its
      first message on this data channel:

      1.  the agent's browser selects for the lifetime of the data
          channel an SCTP outbound stream number not used by any
          channel.

      2.  it then sends the user message over this SCTP stream.

      3.  the peer's browser SACKnowledges the user message, using an
          SCTP stream of same stream number (expectedly unused).  It
          then notifies the peer's application of the data channel
          opening.

   o  Case B: Once the answerer has accepted a new offerer's
      configuration, and has subsequently opened a data channel bound to
      this configuration, the answerer's application may choose to send
      user messages on this channel immediately.  The offerer receiving



Marcon                   Expires August 23, 2013                [Page 9]


Internet-Draft           RTCWeb data management            February 2013


      this message should:

      1.  route this message to one of the Connecting-state data
          channels bound to the same configuration.

      2.  change its state to Open, and sets its SCTP outbound stream
          number (expectedly unused) to the SCTP inbound stream number
          of the message.

      3.  delivers the message to the application.

6.4.  Closing a data channel

   When the application requests to close a data channel, the agent's
   browser initiates an in-band Stream Sequence Number (SSN) reset of
   the related SCTP inbound and outbound streams.  These streams are
   then available for further reuse.

6.5.  Sending and Receiving Data

   To expose to upper layers an API similar to the Web Socket API
   [WSAPI], the agent's browser needs to specify to the peer's browser
   the framing type of each data channel message, amongst binary or text
   (UTF-8).

   In addition, each user message needs to carry the identifier of the
   configuration which the data channel is bound to.

   For the sending of a user message over an opened data channel, the
   agent's browser:

   1.  converts the message data from UTF-16 to UTF-8 if provided by the
       application as a DOMString.

   2.  sets in the DATA chunk the Unordered bit, Payload Protocol
       Identifier and Stream Number as per data channel configuration.

   3.  constructs the User Data field as the framing type byte(s)
       followed by the (converted) message data












Marcon                   Expires August 23, 2013               [Page 10]


Internet-Draft           RTCWeb data management            February 2013


    0                   1                   2                   3
    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
   +------------------------+------+-------------------------------+
   |       Config ID        | Type |          Payload Data         |
   +------------------------+------+ - - - - - - - - - - - - - - - +
   :                     Payload Data continued ...                :
   + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
   |                     Payload Data continued ...                |
   +---------------------------------------------------------------+

                            RTCWeb data framing

   Config ID : 12 bits

      Identifies a data channel configuration negotiated out of band
      between the two endpoints.

         Note: to be considered if the Config ID should be included in
         all user messages.

   Type : 4 bits

      Defines the data framing type of "Payload data".  If an unknown
      type is received, the receiving endpoint must reject the user
      message.  The following values are defined:

      *  x0 denotes a binary frame

      *  x1 denotes a UTF-8 encoded text frame

      *  x2-xFFF are reserved for further use

   An agent's browser receiving a user message on a data channel behaves
   as follows:

   o  If the configuration identifier in the message does not map to any
      negotiated configuration, or if the data channel (identified by
      the message stream number) is in Closing or Connecting state,
      reject (or discard?) the message.

   o  Otherwise (i.e. supported configuration identifier and Open
      state):

         If the endpoint has just sent the very first user message on
         this data channel and has not yet received the SACK, it means
         that both endpoints attempt to dynamically create a data
         channel by the sending of a user message.  In this case, if the
         endpoint has ownership of the signaled configuration, the



Marcon                   Expires August 23, 2013               [Page 11]


Internet-Draft           RTCWeb data management            February 2013


         browser must discard (reject?) the message.

            Note: another way of avoiding this conflict is to state by
            convention that the endpoint which initiated the offer for
            the SCTP association establishment owns all the even stream
            numbers, while the other endpoint owns all the odd stream
            numbers.

         Otherwise deliver the message.

   o  Otherwise (i.e. supported configuration identifier and Closed
      state):

         If a Connecting-state data channel exists with no assigned
         stream number, open it with a stream number set to the message
         stream number.

         If not, open a new data channel with a stream number set to the
         message stream number

         Finally, deliver the message.

6.6.  Out-of-band signaling

   To signal the data channel configurations intended for use during the
   lifetime of an SCTP association, the agent completes the SDP <fmt>
   section of the m=application SDP line defined for the SCTP
   association.  For each data channel configuration previously
   negotiated or newly added at the time of offer generation, the
   agent's browser:

   o  must specify: configuration identifier.

   o  may specify: order of delivery, reliability of delivery,
      subprotocol, subprotocol configuration data.

   As an example in the offer (line split for readability):

   m=application 54111 DTLS/SCTP 5000
   a=sctpmap:5000 webrtc-DataChannel 16
   a=sctp-protocol:5000 config=1;label="channel 1";subprotocol="chat";
   a=sctp-protocol:5000 config=2;label="channel 2";
   subprotocol="file transfer";max_retr=3

               data channel configuration setup in SDP offer

   An in the returned answer (line split for readability):




Marcon                   Expires August 23, 2013               [Page 12]


Internet-Draft           RTCWeb data management            February 2013


   m=application 54111 DTLS/SCTP 5000
   a=sctpmap:5000 webrtc-DataChannel 16
   a=sctp-protocol:5000 config=2;label="channel 2";
   subprotocol="file transfer";max_retr=3

              data channel configuration setup in SDP answer

   In reply to this offer, the peer constructs in the answer the data
   channel configuration list of the SCTP association as follows:

   o  drop any unwanted or unsupported data channel configuration

   o  echo the other configurations, and preserve the following
      properties at least: configuration identifier, subprotocol (if
      any).  Specifies also the peer-specific properties (subprotocol
      setup data).

   This may need to be specified via MMUSIC.


7.  Security Considerations

   To be completed.


8.  IANA Considerations

   To be completed.


9.  Acknowledgments

   The authors wish to thank Richard Ejzak, ... for their invaluable
   comments.


10.  References

10.1.  Normative References

   [I-D.ietf-rtcweb-jsep]
              Uberti, J. and C. Jennings, "Javascript Session
              Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work
              in progress), October 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Marcon                   Expires August 23, 2013               [Page 13]


Internet-Draft           RTCWeb data management            February 2013


   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)
              Partial Reliability Extension", RFC 3758, May 2004.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
              Transmission Protocol (SCTP) Stream Reconfiguration",
              RFC 6525, February 2012.

10.2.  Informative References

   [I-D.ietf-rtcweb-data-channel]
              Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram
              Connection", draft-ietf-rtcweb-data-channel-02 (work in
              progress), October 2012.

   [I-D.jesup-rtcweb-data-protocol]
              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
              Protocol", draft-jesup-rtcweb-data-protocol-03 (work in
              progress), September 2012.

   [ITU.T140.1998]
              "Protocol for Multimedia Application Text Conversation",
              ITU-T Recommendation T.140, February 1998.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [WebRtcAPI]
              Bergkvist, A., Burnett, D., Narayanan, A., and C.
              Jennings, "WebRTC 1.0: Real-time Communication Between
              Browsers", World Wide Web Consortium WD WD-webrtc-
              20120821, August 2012,
              <http://www.w3.org/TR/2012/WD-webrtc-20120821>.

   [WebSocketAPI]
              Hickson, I., "The WebSocket API", World Wide Web
              Consortium LastCall WD-websockets-20120809, August 2012,
              <http://www.w3.org/TR/2012/WD-websockets-20120809>.






Marcon                   Expires August 23, 2013               [Page 14]


Internet-Draft           RTCWeb data management            February 2013


Author's Address

   Jerome Marcon
   Alcatel-Lucent
   Route de Villejust
   Nozay  91620
   France

   Email: jerome.marcon@alcatel-lucent.com










































Marcon                   Expires August 23, 2013               [Page 15]