One document matched: draft-ietf-fecframe-rtp-raptor-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml">
<!ENTITY rfc5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
<!ENTITY rfc2736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2736.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY rfc4855 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4855.xml">
<!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc2326 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml">
<!ENTITY rfc2947 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2947.xml">
<!ENTITY fecframe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-fecframe-framework.xml">
<!ENTITY fecframesdp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-fecframe-sdp-elements.xml">
<!ENTITY raptorschemes SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-fecframe-raptor.xml">
]>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-ietf-fecframe-rtp-raptor-03"
     ipr="trust200902">
  <front>
    <title abbrev="RTP Payload Fromat for Raptor">RTP Payload Format for
    Raptor FEC</title>

    <author fullname="Mark Watson" initials="M." surname="Watson">
      <organization>Qualcomm Inc.</organization>

      <address>
        <postal>
          <street>3165 Kifer Rd.</street>

          <city>Santa Clara</city>

          <region>CA</region>

          <code>95051</code>

          <country>U.S.A.</country>
        </postal>

        <email>watson@qualcomm.com</email>
      </address>
    </author>

    <date day="5" month="March" year="2010" />

    <area>Transport</area>

    <workgroup>FEC Framework Working Group</workgroup>

    <abstract>
      <t>This document specifies an RTP Payload Format for Forward Error
      Correction repair data produced by the Raptor FEC Schemes. Raptor FEC
      Schemes are specified for use with the IETF FEC Framework which supports
      transport of repair data over both UDP and RTP. This document specifies
      the Payload Format which is required for the use of RTP to carry Raptor
      repair flows.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The FEC Framework <xref target="I-D.ietf-fecframe-framework"></xref>
      defines a general framework for the use of Forward Error Correction in
      association with arbitrary packet flows, including flows over UDP and
      RTP <xref target="RFC3550"></xref>. Forward Error Corrections operates
      by generating redundant data packets ("repair data") which can be sent
      independently from the original flow. At a receiver the original flow
      can be reconstructed provided a sufficient set of redundant data packets
      and possibly original data packets are received.</t>

      <t>The FEC Framework provides for independence between application
      protocols and FEC codes. The use of a particular FEC code within the
      framework is defined by means of an FEC Scheme which may then be used
      with any application protocol compliant to the framework.</t>

      <t>Repair data flows may be sent directly over a transport protocol such
      as UDP, or they may be encapsulated within RTP. In the latter case, an
      RTP Payload Format must be defined for each FEC Scheme.</t>

      <t>This document defines the RTP Payload Format for the Raptor FEC
      Schemes defined in <xref target="I-D.ietf-fecframe-raptor"></xref>.</t>
    </section>

    <section title="Conventions, Definitions and Acronyms">
      <t>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 <xref
      target="RFC2119"></xref>.</t>
    </section>

    <section title="Media Format Background">
      <t>The Raptor and RaptorQ codes are efficient block-based fountain
      codes, meaning that from any group of source packets (or 'source block')
      an arbitrary number of repair packets may be generated. The Raptor and
      RaptorQ codes have the property that the original group of source
      symbols can be recovered with very high probability from any set of
      symbols (source and repair) only slightly greater in number than the
      original number of source symbols. The RaptorQ code additionally has the
      property that the probability that the original group of source symbols
      can be recovered from a set of symbols (source and repair) equal in
      number to the original number of source symbols is in many cases also
      very high. </t>

      <t><xref target="I-D.ietf-fecframe-raptor"></xref> defines six FEC
      Schemes for the use of the Raptor and RaptorQ codes with arbitary packet
      flows: the first two schemes are fully applicable to arbitary packet
      flows (using Raptor and RaptorQ respectively). The third and fourth
      schemes are slightly optimised versions of the first two schemes which
      are applicable in applications with relatively small block sizes. The
      fifth and sixth schemes are variants of the third and fourth schemes
      which are applicable to a single source flow which already has some kind
      of identifiable sequence number. The presence of a sequence number in
      the source flow allows for backwards compatible operation (the source
      flows do not need to be modified in order to apply FEC). In this case,
      in the language of the FEC Framework, there is no need for an explicit
      FEC Source Payload Id and it is therefore not included in the
      packets.</t>
    </section>

    <section title="Payload Format">
      <t></t>

      <section title="RTP Header Usage">
        <t>The following rules SHALL be followed for the RTP header used with
        FEC repair packets:</t>

        <t><list style="symbols">
            <t>Marker bit: The marker bit SHALL be set 1 for the last
            protection RTP packet sent for each source block, and otherwise
            set to 0</t>

            <t>Timestamp: The timestamp SHALL be set to a time corresponding
            to the packet's transmission time. The timestamp value has no use
            in the actual FEC protection process. It may be used for packet
            arrival timing and jitter calculations. The timestamp rate SHALL
            be specified using the "rate" media type parameter defined
            below.</t>
          </list>Other header fields SHALL be set according to the rules of
        <xref target="RFC3550"></xref>.</t>
      </section>

      <section title="Payload Header">
        <t>There is no Payload Header in this Payload Format</t>
      </section>

      <section title="Payload Data">
        <t>Procedures and data formats for the use of Raptor Forward Error
        Correction in an FECFRAME context are fully defined in <xref
        target="I-D.ietf-fecframe-framework"></xref> and <xref
        target="I-D.ietf-fecframe-framework"></xref> and are not duplicated
        here. The procedures of those documents SHALL be followed in order to
        generate repair data streams to be carried by the payload formats
        defined in this document.</t>

        <t>The RTP Payload SHALL contain an FEC Repair Payload as defined in
        <xref target="I-D.ietf-fecframe-framework"></xref> and <xref
        target="I-D.ietf-fecframe-raptor"></xref>.</t>
      </section>
    </section>

    <section title="Congestion Control Considerations">
      <t>See <xref target="I-D.ietf-fecframe-framework"></xref>.</t>
    </section>

    <section title="Media Types">
      <section title="Registration of the application/raptorfec media type">
        <t>This RTP payload format is identified using the
        application/raptorfec media type which is registered in accordance
        with <xref target="RFC4855"></xref> and using the template of <xref
        target="RFC4288"></xref>.</t>

        <section anchor="registration-application"
                 title="Media Type Definition">
          <t>Type name: application</t>

          <t>Subtype name: raptorfec</t>

          <t>Required parameters:</t>

          <t><list>
              <t>rate: The RTP timestamp (clock) rate. The rate SHALL be
              larger than 1000 Hz to provide sufficient resolution to RTCP
              operations. However, it is RECOMMENDED to select the rate that
              matches the rate of the protected source RTP stream.</t>

              <t>raptor-scheme-id: The value of this parameter is the FEC
              Scheme Id for the specific Raptor FEC Scheme that will be used
              as defined in <xref
              target="I-D.ietf-fecframe-raptor"></xref>.</t>

              <t>Kmax: The value of this parameter is the FEC Framework
              Configuration Information element "Maximum Source Block Length"
              as defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>T: The value of this parameter is the FEC Framework
              Configuration Information element "Encoding Symbol Size" as
              defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>repair-window: The maximum time that spans the source packets
              and the corresponding repair packets. The size of the repair
              window is specified in microseconds.</t>
            </list></t>

          <t>Optional parameters:</t>

          <t><list>
              <t>P: The value of this parameter is the FEC Framework
              Configuration Information element "Payload ID Format" as defined
              in <xref target="I-D.ietf-fecframe-raptor"></xref>. If this
              parameter is missing that the value "A" shall be assumed.</t>
            </list></t>

          <t>Encoding considerations: This media type is framed and binary,
          see section 4.8 in <xref target="RFC4288"></xref></t>

          <t>Security considerations: Please see security consideration in
          <xref target="I-D.ietf-fecframe-framework"></xref></t>

          <t>Interoperability considerations:</t>

          <t>Published specification: <xref
          target="I-D.ietf-fecframe-raptor"></xref></t>

          <t>Applications that use this media type:</t>

          <t>Additional information:</t>

          <t>Magic number(s): <none defined></t>

          <t>File extension(s): <none defined></t>

          <t>Macintosh file type code(s): <none defined></t>

          <t>Person & email address to contact for further information:
          Mark Watson, watson@qualcomm.com</t>

          <t>Intended usage: COMMON</t>

          <t>Restrictions on usage: This media type depends on RTP framing,
          and hence is only defined for transfer via RTP [<xref
          target="RFC3550"></xref>]. Transport within other framing protocols
          is not defined at this time.</t>

          <t>Author: Mark Watson, Qualcomm Inc.</t>

          <t>Change controller: IETF Audio/Video Transport working group
          delegated from the IESG.</t>
        </section>
      </section>

      <section title="Registration of the video/raptorfec media type">
        <t>This RTP payload format is identified using the video/raptorfec
        media type which is registered in accordance with <xref
        target="RFC4855"></xref> and using the template of <xref
        target="RFC4288"></xref>.</t>

        <section anchor="registration-video" title="Media Type Definition">
          <t>Type name: video</t>

          <t>Subtype name: raptorfec</t>

          <t>Required parameters:</t>

          <t><list>
              <t>rate: The RTP timestamp (clock) rate. The rate SHALL be
              larger than 1000 Hz to provide sufficient resolution to RTCP
              operations. However, it is RECOMMENDED to select the rate that
              matches the rate of the protected source RTP stream.</t>

              <t>raptor-scheme-id: The value of this parameter is the FEC
              Scheme Id for the specific Raptor FEC Scheme that will be used
              as defined in <xref
              target="I-D.ietf-fecframe-raptor"></xref>.</t>

              <t>Kmax: The value of this parameter is the FEC Framework
              Configuration Information element "Maximum Source Block Length"
              as defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>T: The value of this parameter is the FEC Framework
              Configuration Information element "Encoding Symbol Size" as
              defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>repair-window: The maximum time that spans the source packets
              and the corresponding repair packets. The size of the repair
              window is specified in microseconds.</t>
            </list></t>

          <t>Optional parameters:</t>

          <t><list>
              <t>P: The value of this parameter is the FEC Framework
              Configuration Information element "Payload ID Format" as defined
              in <xref target="I-D.ietf-fecframe-raptor"></xref>. If this
              parameter is missing that the value "A" shall be assumed.</t>
            </list></t>

          <t>Encoding considerations: This media type is framed and binary,
          see section 4.8 in <xref target="RFC4288"></xref></t>

          <t>Security considerations: Please see security consideration in
          <xref target="I-D.ietf-fecframe-framework"></xref></t>

          <t>Interoperability considerations:</t>

          <t>Published specification: <xref
          target="I-D.ietf-fecframe-raptor"></xref></t>

          <t>Applications that use this media type:</t>

          <t>Additional information:</t>

          <t>Magic number(s): <none defined></t>

          <t>File extension(s): <none defined></t>

          <t>Macintosh file type code(s): <none defined></t>

          <t>Person & email address to contact for further information:
          Mark Watson, watson@qualcomm.com</t>

          <t>Intended usage: COMMON</t>

          <t>Restrictions on usage: This media type depends on RTP framing,
          and hence is only defined for transfer via RTP [<xref
          target="RFC3550"></xref>]. Transport within other framing protocols
          is not defined at this time.</t>

          <t>Author: Mark Watson, Qualcomm Inc.</t>

          <t>Change controller: IETF Audio/Video Transport working group
          delegated from the IESG.</t>
        </section>
      </section>

      <section title="Registration of the audio/raptorfec media type">
        <t>This RTP payload format is identified using the audio/raptorfec
        media type which is registered in accordance with <xref
        target="RFC4855"></xref> and using the template of <xref
        target="RFC4288"></xref>.</t>

        <section anchor="registration-audio" title="Media Type Definition">
          <t>Type name: audio</t>

          <t>Subtype name: raptorfec</t>

          <t>Required parameters:</t>

          <t><list>
              <t>rate: The RTP timestamp (clock) rate. The rate SHALL be
              larger than 1000 Hz to provide sufficient resolution to RTCP
              operations. However, it is RECOMMENDED to select the rate that
              matches the rate of the protected source RTP stream.</t>

              <t>raptor-scheme-id: The value of this parameter is the FEC
              Scheme Id for the specific Raptor FEC Scheme that will be used
              as defined in <xref
              target="I-D.ietf-fecframe-raptor"></xref>.</t>

              <t>Kmax: The value of this parameter is the FEC Framework
              Configuration Information element "Maximum Source Block Length"
              as defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>T: The value of this parameter is the FEC Framework
              Configuration Information element "Encoding Symbol Size" as
              defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>repair-window: The maximum time that spans the source packets
              and the corresponding repair packets. The size of the repair
              window is specified in microseconds.</t>
            </list></t>

          <t>Optional parameters:</t>

          <t><list>
              <t>P: The value of this parameter is the FEC Framework
              Configuration Information element "Payload ID Format" as defined
              in <xref target="I-D.ietf-fecframe-raptor"></xref>. If this
              parameter is missing that the value "A" shall be assumed.</t>
            </list></t>

          <t>Encoding considerations: This media type is framed and binary,
          see section 4.8 in <xref target="RFC4288"></xref></t>

          <t>Security considerations: Please see security consideration in
          <xref target="I-D.ietf-fecframe-framework"></xref></t>

          <t>Interoperability considerations:</t>

          <t>Published specification: <xref
          target="I-D.ietf-fecframe-raptor"></xref></t>

          <t>Applications that use this media type:</t>

          <t>Additional information:</t>

          <t>Magic number(s): <none defined></t>

          <t>File extension(s): <none defined></t>

          <t>Macintosh file type code(s): <none defined></t>

          <t>Person & email address to contact for further information:
          Mark Watson, watson@qualcomm.com</t>

          <t>Intended usage: COMMON</t>

          <t>Restrictions on usage: This media type depends on RTP framing,
          and hence is only defined for transfer via RTP [<xref
          target="RFC3550"></xref>]. Transport within other framing protocols
          is not defined at this time.</t>

          <t>Author: Mark Watson, Qualcomm Inc.</t>

          <t>Change controller: IETF Audio/Video Transport working group
          delegated from the IESG.</t>
        </section>
      </section>

      <section title="Registration of the text/raptorfec media type">
        <t>This RTP payload format is identified using the text/raptorfec
        media type which is registered in accordance with <xref
        target="RFC4855"></xref> and using the template of <xref
        target="RFC4288"></xref>.</t>

        <section anchor="registration-text" title="Media Type Definition">
          <t>Type name: text</t>

          <t>Subtype name: raptorfec</t>

          <t>Required parameters:</t>

          <t><list>
              <t>rate: The RTP timestamp (clock) rate. The rate SHALL be
              larger than 1000 Hz to provide sufficient resolution to RTCP
              operations. However, it is RECOMMENDED to select the rate that
              matches the rate of the protected source RTP stream.</t>

              <t>raptor-scheme-id: The value of this parameter is the FEC
              Scheme Id for the specific Raptor FEC Scheme that will be used
              as defined in <xref
              target="I-D.ietf-fecframe-raptor"></xref>.</t>

              <t>Kmax: The value of this parameter is the FEC Framework
              Configuration Information element "Maximum Source Block Length"
              as defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>T: The value of this parameter is the FEC Framework
              Configuration Information element "Encoding Symbol Size" as
              defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
              encoded as a decimal integer.</t>

              <t>repair-window: The maximum time that spans the source packets
              and the corresponding repair packets. The size of the repair
              window is specified in microseconds.</t>
            </list></t>

          <t>Optional parameters:</t>

          <t><list>
              <t>P: The value of this parameter is the FEC Framework
              Configuration Information element "Payload ID Format" as defined
              in <xref target="I-D.ietf-fecframe-raptor"></xref>. If this
              parameter is missing that the value "A" shall be assumed.</t>
            </list></t>

          <t>Encoding considerations: This media type is framed and binary,
          see section 4.8 in <xref target="RFC4288"></xref></t>

          <t>Security considerations: Please see security consideration in
          <xref target="I-D.ietf-fecframe-framework"></xref></t>

          <t>Interoperability considerations:</t>

          <t>Published specification: <xref
          target="I-D.ietf-fecframe-raptor"></xref></t>

          <t>Applications that use this media type:</t>

          <t>Additional information:</t>

          <t>Magic number(s): <none defined></t>

          <t>File extension(s): <none defined></t>

          <t>Macintosh file type code(s): <none defined></t>

          <t>Person & email address to contact for further information:
          Mark Watson, watson@qualcomm.com</t>

          <t>Intended usage: COMMON</t>

          <t>Restrictions on usage: This media type depends on RTP framing,
          and hence is only defined for transfer via RTP [<xref
          target="RFC3550"></xref>]. Transport within other framing protocols
          is not defined at this time.</t>

          <t>Author: Mark Watson, Qualcomm Inc.</t>

          <t>Change controller: IETF Audio/Video Transport working group
          delegated from the IESG.</t>
        </section>
      </section>
    </section>

    <section title="Mapping to SDP">
      <t>Applications that are using RTP transport commonly use Session
      Description Protocol (SDP) <xref target="RFC4566"></xref> to describe
      their RTP sessions. The information that is used to specify the media
      types in an RTP session has specific mappings to the fields in an SDP
      description. Note that if an application does not use SDP to describe
      the RTP sessions, an appropriate mapping must be defined and used to
      specify the media types and their parameters for the control/description
      protocol employed by the application.</t>

      <t>The mapping of the above defined payload format media type and its
      parameters SHALL be done according to Section 3 of <xref
      target="RFC4855"></xref> following the suggestion therein regarding the
      mapping of payload-format-specific paraeters into the "<spanx
      style="verb">a=fmtp</spanx>" field.</t>

      <t>When the RTP Payload Formats defined in this document are used, the
      Media Type Parameters defined above SHALL be used to specify the FEC
      Framework Configuration Information in preference to the SDP attributes
      specified in <xref target="I-D.ietf-fecframe-sdp-elements"></xref></t>
    </section>

    <section title="Offer/Answer considerations">
      <t>When offering Raptor FEC over RTP using SDP in an Offer/Answer model
      <xref target="RFC3264"></xref>, the following considerations apply: </t>

      <t><list style="symbols">
          <t>Each combination of the Kmax and T parameters produces different
          FEC data and is not compatible with any other combination. A sender
          application may desire to offer multiple offers with different sets
          of Kmax and T values as long as the parameter values are valid. The
          receiver SHOULD normally choose the offer with the largest value of
          the product of Kmax and T that it supports.</t>

          <t>The size of the repair-window is related to the maximum delay
          between the transmission of a source packet and the associated
          repair packet. This directly impacts the buffering requirement on
          the receiver side and the receiver must consider this when choosing
          an offer.</t>

          <t>When the P parameter is omitted, FEC Payload ID Format A MUST be
          assumed. In an answer which selects an offer in which the P
          parameter was omitted, the P parameter MUST either be omitted, or
          included with value "A".</t>
        </list></t>
    </section>

    <section title="Declarative SDP Considerations">
      <t>In declarative usage, like SDP in the Real-time Streaming Protocol
      (RTSP) <xref target="RFC2326"></xref> or the Session Announcement
      Protocol (SAP) <xref target="RFC2947"></xref>, the following
      considerations apply: </t>

      <t><list style="symbols">
          <t>The payload format configuration parameters are all declarative
          and a participant MUST use the configuration that is provided for
          the session.</t>

          <t>More than one configuration may be provided (if desired) by
          declaring multiple RTP payload types. In that case, the receivers
          should choose the repair flow that is best for them.</t>
        </list></t>
    </section>

    <section title="IANA Considerations">
      <t>This memo requests that IANA registers application/raptorfec as
      specified in <xref target="registration-application"></xref>,
      video/raptorfec as specified in <xref
      target="registration-video"></xref>, audio/raptorfec as specified in
      <xref target="registration-audio"></xref> and text/raptorfec as
      specified in <xref target="registration-text"></xref>. The media type is
      also requested to be added to the IANA registry for "RTP Payload Format
      MIME types" (http://www.iana.org/assignments/rtp-parameters).</t>
    </section>

    <section title="Security Considerations">
      <t>Security Considerations related to the use of the FEC Framework are
      addressed in <xref target="I-D.ietf-fecframe-framework"></xref>. These
      consideration apply in full to users of the RTP Payload Formats defined
      in this document, since these are defined in terms of the FEC
      Framework.</t>

      <t>No further security considerations related specifically to the Raptor
      FEC Schemes defined in <xref target="I-D.ietf-fecframe-raptor"></xref>
      have been identified.</t>

      <t>Users of RTP should consider the Security Considerations of <xref
      target="RFC3550"></xref>.</t>
    </section>
  </middle>

  <back>
    <references>
      &rfc2119;

      &rfc3550;

      &rfc4288;

      &rfc4855;

      &fecframe;

      &fecframesdp;

      &raptorschemes;

      &rfc4566;
      
      &rfc3264;
      
      &rfc2326;
      
      &rfc2947;

    </references>
  </back>
</rfc>