FEC Framework                                                   A. Begen
Internet-Draft                                             Cisco Systems
Intended status:  Informational                           T. Stockhammer
Expires:  March 2, 2009                                 Digital Fountain
                                                         August 29, 2008


              DVB Application-Layer Hybrid FEC Protection
                   draft-ietf-fecframe-dvb-al-fec-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 March 2, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes the Application-layer Forward Error
   Correction (FEC) protocol that was developed by the Digital Video
   Broadcasting (DVB) consortium for the protection of media streams
   over IP networks.  The DVB AL-FEC protocol uses two layers for FEC
   protection.  The first (base) layer is based on the 1-D interleaved
   parity code.  The second (enhancement) layer is based on the Raptor
   code.  By offering a layered approach, the DVB AL-FEC offers a good



Begen & Stockhammer       Expires March 2, 2009                 [Page 1]


Internet-Draft             DVB AL-FEC Protocol               August 2008


   protection against both bursty and random packet losses at a cost of
   decent complexity.  The 1-D interleaved parity code and Raptor code
   have already been specified in separate documents and the current
   document normatively references these specifications.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . .  5
     3.1.  Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Enhancement-Layer FEC  . . . . . . . . . . . . . . . . . .  5
     3.3.  Hybrid Decoding Procedures . . . . . . . . . . . . . . . .  6
   4.  Session Description Protocol (SDP) Signaling . . . . . . . . .  6
   5.  Status of DVB AL-FEC Specification . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8
   Intellectual Property and Copyright Statements . . . . . . . . . . 10



























Begen & Stockhammer       Expires March 2, 2009                 [Page 2]


Internet-Draft             DVB AL-FEC Protocol               August 2008


1.  Introduction

   In 2007, the Digital Video Broadcasting (DVB) consortium published a
   technical specification [ETSI-TS-102-034] through European
   Telecommunications Standards Institute (ETSI).  This specification
   covers several areas related to the transmission of MPEG2 transport
   stream-based services over IP networks.

   The Annex E of [ETSI-TS-102-034] defines an optional protocol for
   Application-layer Forward Error Correction (AL-FEC) to protect the
   streaming media for DVB-IP services carried over RTP [RFC3550]
   transport.  The AL-FEC protocol uses two layers for protection:  a
   base layer that is produced by the 1-D interleaved parity code, and
   an enhancement layer that is produced by the Raptor code.  Whenever a
   receiver supports AL-FEC protocol, the decoding support for the base-
   layer FEC is mandatory while the decoding support for the
   enhancement-layer FEC is optional.  Both the interleaved parity code
   and the Raptor code are systematic FEC codes, meaning that source
   packets are always sent as part of the transport.

   This document briefly explains the DVB AL-FEC protocol by providing
   references to the two FEC codes used as part of the AL-FEC protocol.
   This document considers protection of single-sequence RTP flows only.
   The DVB AL-FEC protocol can protect any type of source media such as
   audio, video, text or application.  The FEC data at each layer is
   generated based on some configuration information, which also
   determines the exact associations and relationships between the
   source and repair packets.  This document shows this configuration
   may be communicated out-of-band in Session Description Protocol (SDP)
   [RFC4566].

   In DVB AL-FEC, the source packets are carried in the source RTP
   stream and the generated FEC repair packets at each layer are carried
   in separate RTP streams.  At the receiver side, if all of the source
   packets are successfully received, there is no need for FEC recovery
   and the repair packets may be discarded.  However, if there are
   missing source packets, the repair packets can be used to recover the
   missing information.

   The block diagram of the encoder side for the systematic DVB AL-FEC
   protection is sketched in Figure 1.  Here, the source packets are fed
   into the parity encoder to produce the parity repair packets.  The
   source packets may also be fed to the Raptor encoder to produce the
   Raptor repair packets.  Source packets as well as the repair packets
   are then sent to the receiver(s) over an IP network.






Begen & Stockhammer       Expires March 2, 2009                 [Page 3]


Internet-Draft             DVB AL-FEC Protocol               August 2008


                              +--------------+
   +--+  +--+  +--+  +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
   +--+  +--+  +--+  +--+     |FEC Protection|    +--+  +--+  +--+  +--+
                              +--------------+
                              |    Parity    | -> +==+  +==+  +==+
                              |    Encoder   |    +==+  +==+  +==+
                              +--------------+
                              |    Raptor    | -> +~~+  +~~+
                              |    Encoder   |    +~~+  +~~+
                              +--------------+

   Source Packet: +--+
                  +--+

   Base-layer Repair Packet: +==+
                             +==+

   Enhancement-layer Repair Packet: +~~+
                                    +~~+

            Figure 1: Block diagram for the DVB AL-FEC encoder

   The block diagram of the decoder side for the systematic DVB AL-FEC
   protection is sketched in Figure 2.  This is a Minimum Performance
   Decoder since the receiver only supports decoding the base-layer
   repair packets.  If there is a loss among the source packets, the
   parity decoder attempts to recover the missing source packets by
   using the base-layer repair packets.


                              +--------------+
   +--+   X     X    +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
   +--+              +--+     |FEC Protection|    +--+  +--+  +--+  +--+
                              +--------------+
         +==+  +==+  +==+ --> |    Parity    |
         +==+  +==+  +==+     |    Decoder   |
                              +--------------+

   Lost Packet: X

      Figure 2: Block diagram for the DVB AL-FEC minimum performance
                                  decoder

   On the other hand, if the receiver supports decoding both the base-
   layer and enhancement-layer repair packets, a combined (hybrid)
   decoding approach is employed to improve the recovery rate of the
   lost packets.  In this case, the decoder is called an Enhanced
   Decoder.  Section 3.3 outlines the procedures for hybrid decoding.



Begen & Stockhammer       Expires March 2, 2009                 [Page 4]


Internet-Draft             DVB AL-FEC Protocol               August 2008


                              +--------------+
   +--+   X     X     X   --> |  Systematic  | -> +--+  +--+  +--+  +--+
   +--+                       |FEC Protection|    +--+  +--+  +--+  +--+
                              +--------------+
         +==+  +==+  +==+ --> |    Parity    |
         +==+  +==+  +==+     |    Decoder   |
                              +--------------+
               +~~+  +~~+ --> |    Raptor    |
               +~~+  +~~+     |    Decoder   |
                              +--------------+

   Lost Packet: X

        Figure 3: Block diagram for the DVB AL-FEC enhanced decoder


2.  Requirements Notation

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


3.  DVB AL-FEC Specification

   The DVB AL-FEC protocol comprises two layers of FEC protection:  1-D
   interleaved parity FEC for the base layer and Raptor FEC for the
   enhancement layer.

3.1.  Base-Layer FEC

   The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation
   to generate the repair symbols.  In a group of D x L source packets,
   the XOR operation is applied to the group of the source packets whose
   sequence numbers are L apart from each other to generate L repair
   packets.  When used in combination with the enhancement layer, the D
   x L block of the source packets protected by one or more FEC packets
   SHALL be wholly contained within a single source block of the Raptor
   code.  Further details of the 1-D interleaved parity code are
   provided in [I-D.begen-fecframe-interleaved-fec-scheme].

3.2.  Enhancement-Layer FEC

   The Raptor code is a fountain code where as many encoding symbols as
   needed can be generated by the encoder on-the-fly from a source data.
   Due to the fountain property of the Raptor code, multiple enhancement
   layers may also be specified, if needed.




Begen & Stockhammer       Expires March 2, 2009                 [Page 5]


Internet-Draft             DVB AL-FEC Protocol               August 2008


   The details of the Raptor code are provided in
   [I-D.watson-fecframe-raptor].  The performances of both the 1-D
   interleaved parity code and Raptor code have been examined in detail
   in [DVB-A115].

3.3.  Hybrid Decoding Procedures

   The receivers that support receiving and decoding both the base and
   enhancement-layer FEC perform hybrid decoding to improve the repair
   performance.  The following steps may be followed to perform hybrid
   decoding:

   1.  Base-layer (Parity) Decoding:  In this step, the repair packets
       that are encoded by the parity encoder are processed as usual to
       repair as many missing source packets as possible.

   2.  Enhancement-layer (Raptor) Decoding:  If there are still missing
       source packets after the first step, the repair packets that are
       Raptor encoded are processed with the source packets already
       received and the source packets that are recovered in the first
       step.

   3.  Hybrid Decoding:  If there are still missing source packets after
       the second step, the unprocessed base-layer (parity) repair
       packets are converted to a form in which they can be added to the
       Raptor decoding process.  With this additional information,
       Raptor decoding may potentially recover any remaining missing
       source packet.

   The procedure that should be followed to benefit from the base-layer
   repair packets in the Raptor decoding process is explained in detail
   in Section E.5.2 of [ETSI-TS-102-034].


4.  Session Description Protocol (SDP) Signaling

   This section provides an SDP [RFC4566] example.  This example uses
   the FEC grouping semantics [RFC4756].

   In this example, we have one source video stream (mid:S1), one FEC
   repair stream (mid:R1) that is produced by the 1-D interleaved parity
   FEC scheme as well as another FEC repair stream (mid:R2) that is
   produced by the Raptor FEC scheme.  We form one FEC group with the
   "a=group:FEC S1 R1 R2" line.  The source and repair streams are sent
   to the same port on different multicast groups.  The repair window is
   set to 200 ms.

   Editor's note:  The payload-format-specific parameters have not been



Begen & Stockhammer       Expires March 2, 2009                 [Page 6]


Internet-Draft             DVB AL-FEC Protocol               August 2008


   defined for Raptor FEC yet.  Once they are defined, the "a=fmtp" for
   the second repair stream will be updated accordingly.

        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.example.com
        s=DVB AL-FEC Example
        t=0 0
        a=group:FEC S1 R1 R2
        m=video 30000 RTP/AVP 100
        c=IN IP4 224.1.1.1/127
        a=rtpmap:100 MP2T/90000
        a=mid:S1
        m=application 30000 RTP/AVP 110
        c=IN IP4 224.1.2.1/127
        a=rtpmap:110 1d-interleaved-parityfec/90000
        a=fmtp:110 L:5; D:10; repair-window: 200000
        a=mid:R1
        m=application 30000 RTP/AVP 111
        c=IN IP4 224.1.3.1/127
        a=rtpmap:111 raptor-fec/90000
        a=fmtp:111 ss-fssi=qwe123; repair-window: 200000
        a=mid:R2


5.  Status of DVB AL-FEC Specification

   At the time of writing this document, there were scheduled updates in
   the DVB AL-FEC specification.  Some parts of these updates will be
   based on the [I-D.begen-fecframe-interleaved-fec-scheme] and
   [I-D.watson-fecframe-raptor].  Further updates (if necessary) in the
   AL-FEC specification may be published by DVB.


6.  Security Considerations

   The are no security considerations in this document.


7.  IANA Considerations

   The are no IANA considerations in this document.


8.  Acknowledgments

   This document is based on [ETSI-TS-102-034].  Thus, the authors would
   like to thank the editors of [ETSI-TS-102-034].




Begen & Stockhammer       Expires March 2, 2009                 [Page 7]


Internet-Draft             DVB AL-FEC Protocol               August 2008


9.  References

9.1.  Normative References

   [I-D.begen-fecframe-interleaved-fec-scheme]
              Begen, A., "1-D Interleaved Parity FEC Scheme for FEC
              Framework", draft-begen-fecframe-interleaved-fec-scheme-00
              (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.

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

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

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4756]  Li, A., "Forward Error Correction Grouping Semantics in
              Session Description Protocol", RFC 4756, November 2006.

9.2.  Informative References

   [ETSI-TS-102-034]
              DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1),
              "Transport of MPEG 2 Transport Stream (TS) Based DVB
              Services over IP Based Networks", March 2007.

   [DVB-A115]
              Available at: http://www.dvb.org/technology/standards/
              a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer
              FEC Evaluations (DVB Document A115)", May 2007.













Begen & Stockhammer       Expires March 2, 2009                 [Page 8]


Internet-Draft             DVB AL-FEC Protocol               August 2008


Authors' Addresses

   Ali Begen
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  abegen@cisco.com


   Thomas Stockhammer
   Digital Fountain
   39141 Civic Center Drive
   Suite 300
   Fremont, CA  94538
   USA

   Email:  stockhammer@digitalfountain.com
































Begen & Stockhammer       Expires March 2, 2009                 [Page 9]


Internet-Draft             DVB AL-FEC Protocol               August 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Begen & Stockhammer       Expires March 2, 2009                [Page 10]