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

Versions: 00 draft-ietf-fecframe-rtp-raptor

FEC Framework Working Group                                    M. Watson
Internet-Draft                                          Digital Fountain
Intended status: Standards Track                        October 22, 2008
Expires: April 25, 2009


                   RTP Payload Format for Raptor FEC
                  draft-watson-fecframe-rtp-raptor-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2009.


















Watson                   Expires April 25, 2009                 [Page 1]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


Abstract

   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions, Definitions and Acronyms  . . . . . . . . . . . .  4
   3.  Media Format Background  . . . . . . . . . . . . . . . . . . .  5
   4.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  RTP Header Usage . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Payload Header . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  Payload Data . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Congestion Control Considerations  . . . . . . . . . . . . . .  7
   6.  Media Types  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Registration of the application/raptorfec media type . . .  8
       6.1.1.  Media Type Definition  . . . . . . . . . . . . . . . .  8
     6.2.  Registration of the video/raptorfec media type . . . . . .  9
       6.2.1.  Media Type Definition  . . . . . . . . . . . . . . . .  9
     6.3.  Registration of the audio/raptorfec media type . . . . . . 10
       6.3.1.  Media Type Definition  . . . . . . . . . . . . . . . . 10
     6.4.  Registration of the text/raptorfec media type  . . . . . . 11
       6.4.1.  Media Type Definition  . . . . . . . . . . . . . . . . 11
   7.  Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Offer/Answer considerations  . . . . . . . . . . . . . . . . . 14
   9.  Declarative SDP Considerations . . . . . . . . . . . . . . . . 15
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20














Watson                   Expires April 25, 2009                 [Page 2]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


1.  Introduction

   The FEC Framework [I-D.ietf-fecframe-framework] defines a general
   framework for the use of Forward Error Correction in association with
   arbitrary packet flows, including flows over UDP and RTP.  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.

   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.

   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.

   This document defines the RTP Payload Format for the Raptor FEC
   Schemes defined in [I-D.watson-fecframe-raptor].





























Watson                   Expires April 25, 2009                 [Page 3]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


2.  Conventions, Definitions and Acronyms

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














































Watson                   Expires April 25, 2009                 [Page 4]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


3.  Media Format Background

   The Raptor code is an efficient XOR-based block-based fountain code,
   meaning that from any group of source packets an arbitrary number of
   repair packets may be generated.  The Raptor code has the property
   that the original group of source packets can be recovered with very
   high probability from any set of packets (source and repair) only
   slightly greater in number than the original number of source
   packets.

   [I-D.watson-fecframe-raptor] defines three FEC Schemes for the use of
   the Raptor code with arbitary packet flows: the first scheme is fully
   applicable to arbitary packet flows.  The second scheme is a slightly
   optimised version of the first scheme which is applicable in
   applications with relatively small block sizes.  The third scheme is
   a variant of the second scheme which is 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 explicit FEC Source Payload Id.






























Watson                   Expires April 25, 2009                 [Page 5]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


4.  Payload Format

   The RTP Payload contains a FEC Repair Payload as defined in
   [I-D.watson-fecframe-raptor].

4.1.  RTP Header Usage

   The rules SHALL be followed for the RTP header used with FEC repair
   packets:

   o  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

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

4.2.  Payload Header

   There is no Payload Header in this Payload Format

4.3.  Payload Data

   The RTP Payload contains a FEC Repair Payload as defined in
   [I-D.ietf-fecframe-framework] and [I-D.watson-fecframe-raptor].

























Watson                   Expires April 25, 2009                 [Page 6]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


5.  Congestion Control Considerations

   See [I-D.ietf-fecframe-framework].
















































Watson                   Expires April 25, 2009                 [Page 7]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


6.  Media Types

6.1.  Registration of the application/raptorfec media type

   This RTP payload format is identified using the application/raptorfec
   media type which is registered in accordance with [RFC4855] and using
   the template of [RFC4288].

6.1.1.  Media Type Definition

   Type name: application

   Subtype name: raptorfec

   Required parameters:

      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
      [I-D.watson-fecframe-raptor]

   Optional parameters: none

   Encoding considerations: This media type is framed and binary, see
   section 4.8 in [RFC4288]

   Security considerations: Please see security consideration in
   [I-D.ietf-fecframe-framework]

   Interoperability considerations:

   Published specification: [I-D.watson-fecframe-raptor]

   Applications that use this media type:

   Additional information:

   Magic number(s): <none defined>

   File extension(s): <none defined>

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

   Person & email address to contact for further information: Mark
   Watson, mark@digitalfountain.com

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing, and



Watson                   Expires April 25, 2009                 [Page 8]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


   hence is only defined for transfer via RTP [[RFC3550]].  Transport
   within other framing protocols is not defined at this time.

   Author: Mark Watson, Digital Fountain

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.

6.2.  Registration of the video/raptorfec media type

   This RTP payload format is identified using the video/raptorfec media
   type which is registered in accordance with [RFC4855] and using the
   template of [RFC4288].

6.2.1.  Media Type Definition

   Type name: video

   Subtype name: raptorfec

   Required parameters:

      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
      [I-D.watson-fecframe-raptor]

   Optional parameters: none

   Encoding considerations: This media type is framed and binary, see
   section 4.8 in [RFC4288]

   Security considerations: Please see security consideration in
   [I-D.ietf-fecframe-framework]

   Interoperability considerations:

   Published specification: [I-D.watson-fecframe-raptor]

   Applications that use this media type:

   Additional information:

   Magic number(s): <none defined>

   File extension(s): <none defined>

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




Watson                   Expires April 25, 2009                 [Page 9]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


   Person & email address to contact for further information: Mark
   Watson, mark@digitalfountain.com

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [[RFC3550]].  Transport
   within other framing protocols is not defined at this time.

   Author: Mark Watson, Digital Fountain

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.

6.3.  Registration of the audio/raptorfec media type

   This RTP payload format is identified using the audio/raptorfec media
   type which is registered in accordance with [RFC4855] and using the
   template of [RFC4288].

6.3.1.  Media Type Definition

   Type name: audio

   Subtype name: raptorfec

   Required parameters:

      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
      [I-D.watson-fecframe-raptor]

   Optional parameters: none

   Encoding considerations: This media type is framed and binary, see
   section 4.8 in [RFC4288]

   Security considerations: Please see security consideration in
   [I-D.ietf-fecframe-framework]

   Interoperability considerations:

   Published specification: [I-D.watson-fecframe-raptor]

   Applications that use this media type:

   Additional information:




Watson                   Expires April 25, 2009                [Page 10]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


   Magic number(s): <none defined>

   File extension(s): <none defined>

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

   Person & email address to contact for further information: Mark
   Watson, mark@digitalfountain.com

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [[RFC3550]].  Transport
   within other framing protocols is not defined at this time.

   Author: Mark Watson, Digital Fountain

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.

6.4.  Registration of the text/raptorfec media type

   This RTP payload format is identified using the text/raptorfec media
   type which is registered in accordance with [RFC4855] and using the
   template of [RFC4288].

6.4.1.  Media Type Definition

   Type name: text

   Subtype name: raptorfec

   Required parameters:

      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
      [I-D.watson-fecframe-raptor]

   Optional parameters: none

   Encoding considerations: This media type is framed and binary, see
   section 4.8 in [RFC4288]

   Security considerations: Please see security consideration in
   [I-D.ietf-fecframe-framework]

   Interoperability considerations:




Watson                   Expires April 25, 2009                [Page 11]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


   Published specification: [I-D.watson-fecframe-raptor]

   Applications that use this media type:

   Additional information:

   Magic number(s): <none defined>

   File extension(s): <none defined>

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

   Person & email address to contact for further information: Mark
   Watson, mark@digitalfountain.com

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP [[RFC3550]].  Transport
   within other framing protocols is not defined at this time.

   Author: Mark Watson, Digital Fountain

   Change controller: IETF Audio/Video Transport working group delegated
   from the IESG.


























Watson                   Expires April 25, 2009                [Page 12]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


7.  Mapping to SDP

   The mapping of the above defined payload format media type and its
   parameters SHALL be done according to Section 3 of [RFC4855]















































Watson                   Expires April 25, 2009                [Page 13]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


8.  Offer/Answer considerations

   None.
















































Watson                   Expires April 25, 2009                [Page 14]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


9.  Declarative SDP Considerations

   None.
















































Watson                   Expires April 25, 2009                [Page 15]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


10.  IANA Considerations

   This memo requests that IANA registers application/raptorfec as
   specified in Section 6.1.1, video/raptorfec as specified in
   Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and
   text/raptorfec as specified in Section 6.4.1.  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).











































Watson                   Expires April 25, 2009                [Page 16]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


11.  Security Considerations

   See [I-D.ietf-fecframe-framework]
















































Watson                   Expires April 25, 2009                [Page 17]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


12.  References

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

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
              Payload Format Specifications", BCP 36, RFC 2736,
              December 1999.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.

   [I-D.ietf-fecframe-framework]
              Watson, M., "Forward Error Correction (FEC) Framework",
              draft-ietf-fecframe-framework-02 (work in progress),
              July 2008.

   [I-D.watson-fecframe-raptor]
              Watson, M., "Raptor FEC Schemes for FECFRAME",
              draft-watson-fecframe-raptor-00 (work in progress),
              July 2008.













Watson                   Expires April 25, 2009                [Page 18]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


Author's Address

   Mark Watson
   Digital Fountain
   39141 Civic Center Drive
   Suite 300
   Fremont, CA  94538
   U.S.A.

   Email: mark@digitalfountain.com









































Watson                   Expires April 25, 2009                [Page 19]

Internet-Draft        RTP Payload Fromat for Raptor         October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Watson                   Expires April 25, 2009                [Page 20]


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