--- 1/draft-ietf-rtcweb-data-protocol-02.txt 2014-02-11 06:14:36.686760132 -0800 +++ 2/draft-ietf-rtcweb-data-protocol-03.txt 2014-02-11 06:14:36.710760720 -0800 @@ -1,21 +1,21 @@ Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: August 13, 2014 Ericsson +Expires: August 15, 2014 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - February 9, 2014 + February 11, 2014 - WebRTC Data Channel Protocol - draft-ietf-rtcweb-data-protocol-02.txt + WebRTC Data Channel Establishment Protocol + draft-ietf-rtcweb-data-protocol-03.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 a simple protocol for establishing symmetric data channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. @@ -28,21 +28,21 @@ 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 13, 2014. + This Internet-Draft will expire on August 15, 2014. Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,23 +69,24 @@ 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informational References . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction - The data channel protocol is designed to provide, in the WebRTC data - channel context [I-D.ietf-rtcweb-data-channel], a simple in-band - method to open symmetric data channels. As discussed in + The Data Channel Establishment Protocol (DCEP) is designed to + provide, in the WebRTC data channel context + [I-D.ietf-rtcweb-data-channel], a simple in-band method to open + symmetric data channels. As discussed in [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transport Layer Security (DTLS) [RFC6347] as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already standardized transport and security features. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -119,55 +120,57 @@ is used. o whether the messages are delivered in-order or out-of order. o an optional label for the Channel. o an optional protocol for the Channel. o the SCTP streams. - The data channel protocol uses a two way handshake to open a data - channel by combining two SCTP streams, one in each direction, with - the same SCTP stream identifier. The side wanting to open a data - channel selects an SCTP stream identifier for which the corresponding - incoming and outgoing SCTP stream is unused and sends a + The Data Channel Establishment Protocol uses a two way handshake to + open a data channel by combining two SCTP streams, one in each + direction, with the same SCTP stream identifier. The side wanting to + open a data channel selects an SCTP stream identifier for which the + corresponding incoming and outgoing SCTP stream is unused and sends a DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer responds with a DATA_CHANNEL_ACK message on its corresponding outgoing SCTP stream. Then the data channel is open. Please note that the opening side can send user messages before the DATA_CHANNEL_ACK is received. Data channel messages are sent on the same Stream as the user messages belonging to the data channel. The demultiplexing is based on the SCTP payload protocol identifier - (PPID), since the data channel protocol uses a specific PPID. + (PPID), since the Data Channel Establishment Protocol uses a specific + PPID. To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers. Note: There is no attempt to resolve label glare; if both sides open a Channel labeled "x" at the same time, there will be two Channels labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation ("federation") by identifying the user data being passed with an IANA-registered string (see Section 8.4), and may be useful for homogenous applications which may create more than one type of Channel. 5. Message Formats - Every data channel protocol message starts with a one byte field - called "Message Type" which indicates the type of the message. The - corresponding values are managed by IANA (see Section 8.2). + Every Data Channel Establishment Protocol message starts with a one + byte field called "Message Type" which indicates the type of the + message. The corresponding values are managed by IANA (see + Section 8.2). 5.1. DATA_CHANNEL_OPEN Message This message is sent initially on the stream used for user messages using the channel. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Channel Type | Priority | @@ -276,34 +278,36 @@ | Message Type | +-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the the DATA_CHANNEL_ACK message. The suggested value of this field for IANA is 0x02. 6. Procedures - All data channel protocol messages MUST be sent requesting ordered - delivery and using reliable transmission. They MUST be sent on the - same outgoing SCTP stream as the user messages belonging to the - corresponding data channel. Multiplexing and demultiplexing is done - by using the SCTP payload protocol identifier (PPID). Therefore data - channel protocol message MUST be sent with the assigned PPID for the - data channel protocol (see Section 8.1). Other message MUST NOT be - sent using this PPID. + All Data Channel Establishment Protocol messages MUST be sent + requesting ordered delivery and using reliable transmission. They + MUST be sent on the same outgoing SCTP stream as the user messages + belonging to the corresponding data channel. Multiplexing and + demultiplexing is done by using the SCTP payload protocol identifier + (PPID). Therefore Data Channel Establishment Protocol message MUST + be sent with the assigned PPID for the Data Channel Establishment + Protocol (see Section 8.1). Other message MUST NOT be sent using + this PPID. - If one sides wants to open a data channel, it chooses a free outgoing - SCTP stream. If the side is the DTLS client, it MUST choose an even - stream identifier, if the side is the DTLS server, it MUST choose an - odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message - and sends it on the chosen SCTP stream. + If one sides wants to open a data channel, it chooses an SCTP stream + identifier for which the corresponding incoming and outgoing SCTP + streams are free. If the side is the DTLS client, it MUST choose an + even stream identifier, if the side is the DTLS server, it MUST + choose an odd one. It fills in the parameters of the + DATA_CHANNEL_OPEN message and sends it on the chosen SCTP stream. After the DATA_CHANNEL_OPEN message has been sent, the sender of it can start sending messages containing user data without waiting for the reception of the corresponding DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK message or any other message has been received on the data channel, all other messages containing user data and belonging to the data channel MUST be sent ordered, not matter whether the data channel is ordered or not. After the DATA_CHANNEL_ACK or any other message has been received on the data channel, messages containing user data MUST be send ordered on @@ -341,50 +345,54 @@ 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] IANA is asked to update the reference of an already existing SCTP - PPID assignment and to create three new registries for the data - channel protocol. + PPID assignment and to create three new registries for the Data + Channel Establishment Protocol. 8.1. SCTP Payload Protocol Identifier This document uses one already registered SCTP Payload Protocol - Identifier (PPID). [RFC4960] creates the registry "SCTP Payload - Protocol Identifiers" from which this identifier was assigned. IANA - is requested to update the reference of this assignment to point to - this document. Therefore this assignment should be updated to read: + Identifier (PPID) named "WebRTC Control". [RFC4960] creates the + registry "SCTP Payload Protocol Identifiers" from which this + identifier was assigned. IANA is requested to update the reference + of this assignment to point to this document and to update the name. + Therefore this assignment should be updated to read: - +----------------+-----------+-----------+ + +-------------+-----------+-----------+ | Value | SCTP PPID | Reference | - +----------------+-----------+-----------+ - | WebRTC Control | 50 | [RFCXXXX] | - +----------------+-----------+-----------+ + +-------------+-----------+-----------+ + | WebRTC DCEP | 50 | [RFCXXXX] | + +-------------+-----------+-----------+ 8.2. New Message Type Registry IANA is requested to create a new registration table "Message Type - Registry" for the data channel protocol to manage the one byte - "Message Type" field in data channel messages (see Section 5). + Registry" for the Data Channel Establishment Protocol (DCEP) to + manage the one byte "Message Type" field in DCEP messages (see + Section 5). The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new message type MUST contain the following information: 1. A name for the new message type; + 2. A detailed procedural description of the use of messages with the - new type within the operation of the data channel protocol. + new type within the operation of the Data Channel Establishment + Protocol. Initially the following values need to be registered: +-------------------+-----------+-----------+ | Name | Type | Reference | +-------------------+-----------+-----------+ | Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | @@ -392,22 +400,23 @@ | Reserved | 0xff | [RFCXXXX] | +-------------------+-----------+-----------+ Please note that the values 0x00 and 0x01 are reserved to avoid interoperability problems, since they have been used in earlier versions of the document. 8.3. New Channel Type Registry IANA is requested to create a new registration table "Channel Type - Registry" for the data channel protocol to manage the one byte - "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). + Registry" for the Data Channel Establishment Protocol to manage the + one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see + Section 5.1). The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new channel type MUST contain the following information: 1. A name for the new channel type; 2. A detailed procedural description of the user message handling for data channels using this new channel type. @@ -427,39 +436,40 @@ | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] | | Unassigned | rest | | +------------------------------------------------+------+-----------+ 8.4. New Protocol Registry IANA is requested to create a new registration table "Protocol - Registry" for the data channel protocol to manage the "Protocol" - field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1). + Registry" for the Data Channel Establishment Protocol to manage the + "Protocol" field of type string in DATA_CHANNEL_OPEN messages (see + Section 5.1). The assignment of new message types is done through an First Come First Served action, as defined in [RFC5226]. Documentation of the new protocol MUST contain the following information: 1. A name for the protocol; 2. A reference for the protocol indicated by the registered string. Initially this registry is empty. 9. Acknowledgments - The authors wish to thank Martin Thompson, Cullen Jennings, Harald - Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall - Stewart, Stefan Haekansson and many others for their invaluable - comments. + The authors wish to thank Harald Alvestrand, Adam Bergkvist, Barry + Dingle, Stefan Haekansson, Cullen Jennings, Randall Stewart, Peter + Thatcher, Martin Thompson, Justin Uberti, and many others for their + invaluable comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.