<?xml version='1.0' encoding='utf-8'?>
<?xml-model href="rfc7991bis.rnc"?>
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     xml:lang="en"
     ipr="trust200902"
     submissionType="IETF"
     consensus="true"
     category="std"
     docName="draft-tuexen-tsvwg-sctp-ppid-frag-03"
     version="3">

<front>
<title abbrev='PPID based Frag. and Reass. for SCTP'>
Payload Protocol Identifier based Fragmentation and Reassembly for the Stream
Control Transmission Protocol
</title>
<seriesInfo name="Internet-Draft" value="draft-tuexen-tsvwg-sctp-ppid-frag-03"/>

<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
  <organization abbrev='Münster Univ. of Appl. Sciences'>
                Münster University of Applied Sciences</organization>
  <address>
    <postal>
        <street>Stegerwaldstrasse 39</street>
        <city>48565 Steinfurt</city>
        <country>Germany</country>
    </postal>
    <email>tuexen@fh-muenster.de</email>
  </address>
</author>

<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization abbrev='Mozilla'>
              Mozilla Corporation</organization>
<address>
    <postal>
        <street>1835 Horse Shoe Trl</street>
        <city>Malvern</city>
        <region>PA</region>
        <code>19355</code>
        <country>US</country>
    </postal>
    <email>randell-ietf@jesup.org</email>
</address>
</author>

<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<address>
    <email>hannes.tschofenig@gmx.net</email>
</address>
</author>

<date />

<abstract>
<t>This document describes a method for the Stream Control Transmission
Protocol (SCTP) allowing the upper layer to perform fragmentation, reassembly,
and interleaving of large ordered user messages by using the payload
protocol identifier (PPID).</t>
<t>According to the base specification supporting fragmentation of large user
messages is optional.
And even if an SCTP implementation supports fragmentation, interleaving of user
messages is not supported by the base specification.</t>
</abstract>
</front>

<middle>

<section>
<name>Introduction</name>
<t></t>
<t>This document specifies a method to use PPIDs for fragmenting ordered
large user messages.
Using this method also allows the ability to interleave large user messages as
provided by <xref target="RFC8260"/> in combination with using the
SCTP_FRAGMENT_INTERLEAVE level_2 as described
<xref target="RFC6458"/>, Section 8.1.20.</t>
<t>Reasons to use this method include:</t>
<ul>
<li><t>The fragmentation of large user messages is only an optional feature of
SCTP implementations compliant <xref target="RFC9260"/>.
Therefore, if an implementation does not support fragmentation, it is impossible
to send large user messages requiring fragmentation.</t></li>
<li><t>An SCTP implementation supporting <xref target="RFC9260"/>, but not
<xref target="RFC8260"/>, does not allow the interleaving of large user
messages.
</t></li>
</ul>
<t>This method does not apply to user messages sent using partial reliability
as described in <xref target="RFC3758"/>.</t>
<t>The idea described in this document was already described in
<xref target="I-D.ietf-rtcweb-data-channel"/>.
In the final specification <xref target="RFC8831"/>, this method is declared
deprecated.</t>
</section>

<section anchor='conventions'>
<name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</section>

<section>
<name>Sender Side Considerations</name>
<t>An upper layer splits a user message in one or more user message fragments.
The upper layer <bcp14>SHOULD</bcp14> choose the size of the user message
fragments such than SCTP level fragmentation is avoided.</t>
<t>The upper layer uses two PPIDs.
It <bcp14>MUST</bcp14> use one PPID for all user messages fragments except the
last one, and it <bcp14>MUST</bcp14> the other PPID for the last user message
fragments.</t>
<t>All user message fragments belonging to the same user message
<bcp14>MUST</bcp14> be sent on the same stream, reliable, and ordered in the
sequence they belong to the user message.
User message fragments sent on different stream <bcp14>MAY</bcp14> be sent
in any order.
This allows the interleaving of user messages sent on different
streams.</t>
<t>User messages not requiring to be split into multiple user message fragments
are sent as a single user message fragment with the PPID used for last user
fragments.</t>
</section>

<section>
<name>Receiver Side Considerations</name>
<t>The upper layer <bcp14>MUST</bcp14> process user message fragments received
on different streams independently.
All user message fragments are received by the upper layer in the correct
ordering and the PPID <bcp14>MUST</bcp14> be used to reconstruct the user
message boundaries.
A user message fragment with the PPID marking the last user message fragment
is the last fragment of a use message.
The next received user message fragment on the stream is the first fragment of
the next user message.</t>
<t>An upper layer <bcp14>MUST</bcp14> deal with interleaving of user
messages.</t>
<t>Please note that notifications, if enabled, can be provided by the SCTP
implementation at any time.</t>
</section>

<section>
<name>Socket API Considerations</name>
<t>This document does not require and changes or additions to the Socket API
described in <xref target="RFC6458"/>.</t>
</section>

<section>
<name>IANA Considerations</name>
<t>This document does not make any requests for IANA.</t>
</section>

<section>
<name>Security Considerations</name>
<t>This document does not change the considerations given in
<xref target="RFC9260"/>.</t>
</section>
</middle>

<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/>
</references>

<references>
<name>Informative References</name>
<reference anchor="I-D.ietf-rtcweb-data-channel" target="https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel-06">
<front>
<title>WebRTC Data Channels</title>
<author fullname="Randell Jesup" initials="R." surname="Jesup">
<organization>Mozilla</organization>
</author>
<author fullname="Salvatore Loreto" initials="S." surname="Loreto">
<organization>Ericsson</organization>
</author>
<author fullname="Michael Tüxen" initials="M." surname="Tüxen">
<organization>Muenster Univ. of Appl. Sciences</organization>
</author>
<date day="21" month="October" year="2013"/>
<abstract>
<t>The WebRTC framework specifies protocol support for direct, interactive, rich
communication using audio, video, and data between two peers' web browsers. This
document specifies the non-media data transport aspects of the WebRTC framework.
It provides an architectural overview of how the Stream Control Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport service
that allows web browsers to exchange generic data from peer to peer.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-channel-06"/>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6458.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8260.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8831.xml"/>
</references>
</references>

<!--
<section numbered='false'>
<name>Acknowledgments</name>
<t>The authors wish to thank
<contact fullname="Gorry Fairhurst"/>,
<contact fullname="Mike Heard"/>,
<contact fullname="Peter Lei"/>,
<contact fullname="Nils Ohlmeier"/>,
<contact fullname="Claudio Porfiri"/>,
<contact fullname="Greg Skinner"/>,
<contact fullname="Timo Völker"/>, and
<contact fullname="Magnus Westerlund"/>
for their invaluable comments.</t>
</section>
-->
</back>
</rfc>