Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel
RFC 8850

Document Type RFC - Experimental (January 2021; No errata)
Author Christer Holmberg 
Last updated 2021-01-18
Replaces draft-holmberg-clue-datachannel
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Paul Kyzivat
Shepherd write-up Show (last changed 2016-05-30)
IESG IESG state RFC 8850 (Experimental)
Action Holders
(None)
Consensus Boilerplate Yes
Telechat date
Responsible AD Adam Roach
Send notices to "Paul Kyzivat" <pkyzivat@alum.mit.edu>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack


Internet Engineering Task Force (IETF)                       C. Holmberg
Request for Comments: 8850                                      Ericsson
Category: Experimental                                      January 2021
ISSN: 2070-1721

     Controlling Multiple Streams for Telepresence (CLUE) Protocol
                              Data Channel

Abstract

   This document defines how to use the WebRTC data channel mechanism to
   realize a data channel, referred to as a Controlling Multiple Streams
   for Telepresence (CLUE) data channel, for transporting CLUE protocol
   messages between two CLUE entities.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  It represents the consensus of the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents approved by the IESG are candidates for any level of
   Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8850.

Copyright Notice

   Copyright (c) 2021 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
   Provisions Relating to IETF Documents
   (https://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
   2.  Conventions
   3.  CLUE Data Channel
     3.1.  General
     3.2.  SCTP Considerations
       3.2.1.  General
       3.2.2.  SCTP Payload Protocol Identifier (PPID)
       3.2.3.  Reliability
       3.2.4.  Order
       3.2.5.  Stream Reset
       3.2.6.  SCTP Multihoming
       3.2.7.  Closing the CLUE Data Channel
     3.3.  SDP Considerations
       3.3.1.  General
       3.3.2.  SDP dcmap Attribute
       3.3.3.  SDP dcsa Attribute
       3.3.4.  Example
   4.  Security Considerations
   5.  IANA Considerations
     5.1.  Subprotocol Identifier "clue"
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgements
   Author's Address

1.  Introduction

   This document defines how to use the WebRTC data channel mechanism
   [RFC8831] to realize a data channel, referred to as a Controlling
   Multiple Streams for Telepresence (CLUE) data channel, for
   transporting CLUE protocol messages [RFC8847] between two CLUE
   entities.

   This document also defines how to describe the SCTPoDTLS association
   [RFC8261] (also referred to as "SCTP over DTLS" in this document)
   used to realize the CLUE data channel using the Session Description
   Protocol (SDP) [RFC4566] and defines usage of the SDP-based "SCTP
   over DTLS" data channel negotiation mechanism [RFC8864].  ("SCTP"
   stands for "Stream Control Transmission Protocol".)  This includes
   SCTP considerations specific to a CLUE data channel, the SDP media
   description ("m=" line) values, and usage of SDP attributes specific
   to a CLUE data channel.

   Details and procedures associated with the CLUE protocol, and the SDP
   Offer/Answer procedures [RFC3264] for negotiating usage of a CLUE
   data channel, are outside the scope of this document.

      |  NOTE: The usage of the Data Channel Establishment Protocol
      |  (DCEP) [RFC8832] for establishing a CLUE data channel is
      |  outside the scope of this document.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   SCTPoDTLS association
      Refers to an SCTP association carried over a DTLS connection
      [RFC8261].

   WebRTC data channel
      Refers to a pair of SCTP streams over an SCTPoDTLS association
      that is used to transport non-media data between two entities, as
      defined in [RFC8831].

   CLUE data channel
      Refers to a WebRTC data channel realization [RFC8831], with a
      specific set of SCTP characteristics, with the purpose of
      transporting CLUE protocol messages [RFC8847] between two CLUE
      entities.

   CLUE entity
Show full document text