[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-ietf-rtcweb-data-protocol

RTCWeb Working Group                                            R. Jesup
Internet-Draft                                                   Mozilla
Intended status: Standards Track                               S. Loreto
Expires: September 7, 2012                                      Ericsson
                                                               M. Tuexen
                                          Muenster University of Applied
                                                                Sciences
                                                           March 6, 2012


                      WebRTC Data Channel Protocol
                draft-jesup-rtcweb-data-protocol-00.txt

Abstract

   The Web Real-Time Communication (WebRTC) working group is charged to
   provide protocols to support for direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  This document specifies an actual (minor) protocol for how
   the JS-layer dataChannel objects provide the data channels between
   the peers.

   This minor protocol has applicability to other bidirectional uses of
   SCTP.

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 September 7, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Jesup, et al.           Expires September 7, 2012               [Page 1]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


   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.  Opening handshake . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Control Messages  . . . . . . . . . . . . . . . . . . . . . . . 3
     4.1.  Adding a Channel  . . . . . . . . . . . . . . . . . . . . . 6
     4.2.  Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6
   5.  Sending and Receiving Data  . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informational References  . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
























Jesup, et al.           Expires September 7, 2012               [Page 2]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


1.  Introduction

   The Data Channel Protocol is designed to provide, in the WebRTC
   context [I-D.ietf-rtcweb-overview], a generic transport service
   allowing Web Browser to exchange generic data in a bidirectional peer
   to peer fashion.  As discussed in [I-D.jesup-rtcweb-data] the
   protocol uses Stream Control Transmission Protocol (SCTP) [RFC4960]
   encapsulated on Datagram Transport Layer Security (DTLS) [RFC6347] to
   benefit from their transport and security already standardized
   features.


2.  Opening handshake

   The opening handshake is based on the multimedia session description
   exchange that happens between the browsers, typically through a Web
   Server acting as the signaling service.

   The draft [I-D.ietf-mmusic-sctp-sdp] defines the protocol identifier,
   'SCTP/DTLS', and defines how to establish an SCTP association over
   DTLS using the Session Description Protocol (SDP).

   The SCTP association is created with the number of streams specified
   by the application, and if not specified, then it shall default to 16
   streams.

   It is recommended that additional streams be available dynamically
   based on [RFC6525].


3.  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.1.  Terminology

   This document uses the following terms:

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


4.  Control Messages

   Data Channel Control Messages are sent to manage opening



Jesup, et al.           Expires September 7, 2012               [Page 3]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


   bidirectional channels.  A DATA_CHANNEL_OPEN is sent on the Stream
   that is intended to be used to send in that direction, and a response
   (DATA_CHANNEL_OPEN_RESPONSE) using the same structure is sent back on
   the Stream to be used for the other direction, with a
   reverse_direction_stream entry holding the Stream number the
   DATA_CHANNEL_OPEN was sent on.  This allows association of the
   Streams that define the bidirectional channel.

   Errors are returned by setting the first 16 bits of the msg_type_data
   field to a non-0 value.  In this case the original sender of
   DATA_CHANNEL_OPEN shall close the channel.








































Jesup, et al.           Expires September 7, 2012               [Page 4]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0    | Reserved|U|B|E|    Length                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              TSN                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Stream Identifier S      |   Stream Sequence Number n    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        PPID = Data Channel Control            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  msg_type     | channel_type  |         flags                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   reverse_direction_stream    |   reliability_parameters      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   msg_type_data                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       \                                                               \
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         'msg_type' contains:
              DATA_CHANNEL_OPEN                     0
              DATA_CHANNEL_OPEN_RESPONSE            1

         'channel_type' contains:
              DATA_CHANNEL_RELIABLE                 0
              DATA_CHANNEL_RELIABLE_STREAM          1
              DATA_CHANNEL_UNRELIABLE               2
              DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT  3
              DATA_CHANNEL_PARTIAL_RELIABLE_TIMED   4

         'flags' contains:
              DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED 0x0001
              all other bits are reserved

         'msg_type_data' contains:
              for DATA_CHANNEL_OPEN:
                  a DOMString label for the data channel
              for DATA_CHANNEL_OPEN_RESPONSE:
                  a 16-bit value for errors or 0 for no error

         'reliability_parameters' contains (as unsigned 16-bit numbers):
              for DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT:
                  the maximum number of retransmits or 0 for none
              for DATA_CHANNEL_PARTIAL_RELIABLE_TIMED:
                  the maximum time in ms to attempt to deliver the data
                  or 0 for no attempts.



Jesup, et al.           Expires September 7, 2012               [Page 5]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


      Figure 1: Data Channel control messages: OPEN and OPEN_RESPONSE
                                 Messages

   Note that the forward and reverse-direction Stream numbers may be
   different if both sides attempt to open the same Stream number at the
   same time, and the protocol does not require they be the same.

   Control messages shall be sent on the relevant Streams, and shall be
   sent using reliable, in-order delivery.

4.1.  Adding a Channel

   When one side wants to add a channel, it picks an unused Stream, and
   if need be, negotiates an increase in the number of Streams
   available.  It then sends a DATA_CHANNEL_OPEN control message on the
   Stream, with reverse_direction_stream set to 0, though that value
   MUST be ignored by the recipient.

   When a DATA_CHANNEL_OPEN is received on a Stream, an unused Stream is
   picked, and if need be, negotiates an increase in the number of
   Streams available.  A DATA_CHANNEL_OPEN_RESPONSE is sent on the
   Stream, with reverse_direction_stream set to the Stream the
   DATA_CHANNEL_OPEN request came in on.

   When a DATA_CHANNEL_OPEN_RESPONSE is received, the
   reverse_direction_stream value is matched against all pending
   DATA_CHANNEL_OPENs.  If no match can be found, the
   DATA_CHANNEL_OPEN_RESPONSE should be ignored.  If a match is found,
   then if the error value is 0 the bidirectional Data Channel is now
   established and ready for use.  If the error value is non-zero, the
   open failed, and the originator should close down the originally-
   selected Stream and notify the application.

   An alternative to embedding the control messages on the Streams used
   for data transfer would be to put them on a reserved Stream (0 for
   example), and add an additional field for the
   forward_direction_stream.

   The channel_type and reliability_parameters fields of the
   DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of
   the Data Channel so that both directions use the same options.

4.2.  Closing a Channel

   Data Channels shall be closed by doing an SCTP Stream Sequence Number
   reset, which should guarantee that all data sent before closing is
   delivered or has been abandoned (for partially-reliable Data
   Channels).



Jesup, et al.           Expires September 7, 2012               [Page 6]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


5.  Sending and Receiving Data

   Data shall be sent using PPID's other than the Data Channel Control
   PPID.  These PPID's should be registered with IANA via (TBD).  The
   meaning of these data PPIDs and the format of the data shall be
   specific to the usage of this protocol, and typically shall be
   provided to the higher layers to allow proper decoding of the data.

   For WebRTC, data PPID's for DOMStrings and binary data blobs shall be
   created.

   All data sent on a Data Channel in both directions MUST be sent over
   the underlying Stream using the reliability defined when the Data
   Channel was opened.

   It is recommended that message size be kept within certain bounds
   (TBD).


6.  Security Considerations

   To be done.


7.  IANA Considerations

   This document also defines three new SCTP Payload Protocol
   Identifiers (PPIDs).  RFC 4960 [RFC4960] creates the registry from
   which these identifiers have been assigned.  The following values
   have been reserved:

   WebRTC Control -  #To Be Assigned
   DOMString -  #To Be Assigned
   Binary Data -  #To Be Assigned


8.  Acknowledgments

   Many thanks for comments, ideas, and text ...  (TBD)


9.  References

9.1.  Normative References

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




Jesup, et al.           Expires September 7, 2012               [Page 7]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


   [I-D.ietf-mmusic-sctp-sdp]
              Loreto, S. and G. Camarillo, "Stream Control Transmission
              Protocol (SCTP)-Based Media Transport in the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-00
              (work in progress), July 2011.

   [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.

9.2.  Informational References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-02 (work
              in progress), September 2011.

   [I-D.jesup-rtcweb-data]
              Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram
              Connection", draft-jesup-rtcweb-data-01 (work in
              progress), October 2011.


Authors' Addresses

   Randell Jesup
   Mozilla
   USA

   Email: randell-ietf@jesup.org


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: salvatore.loreto@ericsson.com






Jesup, et al.           Expires September 7, 2012               [Page 8]

Internet-Draft         data protocol P2P in RTCWEB            March 2012


   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   Steinfurt  48565
   Germany

   Email: tuexen@fh-muenster.de












































Jesup, et al.           Expires September 7, 2012               [Page 9]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/