FEC Framework                                                   A. Begen
Internet-Draft                                             Cisco Systems
Intended status:  Informational                           T. Stockhammer
Expires:  February 12,  March 20, 2010                                  Nomor Research
                                                         August 11,
                                                      September 16, 2009

              DVB

            DVB-IPTV Application-Layer Hybrid FEC Protection
                   draft-ietf-fecframe-dvb-al-fec-02
                   draft-ietf-fecframe-dvb-al-fec-03

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 February 12, March 20, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes

   The Annex E of the DVB-IPTV technical specification defines an
   optional Application-layer Forward Error Correction (FEC) (AL-FEC) protocol that was developed by the Digital Video
   Broadcasting (DVB) consortium for
   to protect the protection of streaming media streams carried over IP networks. RTP transport.  The DVB DVB-
   IPTV 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 DVB-IPTV AL-FEC protocol offers a good
   protection against both bursty and random packet losses at a cost of
   decent complexity.  The  This document describes how one can implement the
   DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and
   Raptor code that have already been specified in separate documents and the current
   document normatively references these specifications. documents.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  DVB  DVB-IPTV AL-FEC Specification  . . . . . . . . . . . . . . . . . . .  5
     3.1.
     2.1.  Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.
     2.2.  Enhancement-Layer FEC  . . . . . . . . . . . . . . . . . .  7
     3.3.
     2.3.  Hybrid Decoding Procedures . . . . . . . . . . . . . . . .  8
   4.
   3.  Session Description Protocol (SDP) Signaling . . . . . . . . .  8
   5.
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the
   Digital Video Broadcasting (DVB) consortium published a technical
   specification [ETSI-TS-102-034v1.3.1] 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-034v1.3.1] 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.  In 2008, 2009, DVB updated the specification in a new revision
   that has been published as a DVB Bluebook [DVB-A086r7] [DVB-A086r8] and serves as
   draft ETSI TS-102-034v1.4.1 until the final ETSI publication
   (expected in early late 2009).  Among others, some updates and modifications
   to the AL-FEC protocol have been made.

   The DVB DVB-IPTV AL-FEC protocol uses two layers for protection:  a base
   layer that is produced by the 1-D interleaved parity code, code (also
   simply referred to as parity code in the remainder of this document),
   and an enhancement layer that is produced by the Raptor code.
   Whenever a receiver supports the DVB DVB-IPTV 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 not modified in any way during the
   FEC encoding process.

   The normative DVB DVB-IPTV AL-FEC protocol considers protection of single-
   sequence
   single-sequence source RTP flows only.  The source can be any type of media
   such as audio, video, text or application.  However, in  In the AL-FEC protocol, the
   source stream can only be an MPEG-2 transport stream.  The FEC data
   at each layer are generated based on some configuration information,
   which also determines the exact associations and relationships
   between the source and repair packets.  This document shows how this
   configuration may be communicated out-of-band in the Session
   Description Protocol (SDP) [RFC4566].

   In DVB DVB-IPTV 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 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 DVB-IPTV 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.

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

   Source Packet: +--+
                  +--+

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

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

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

   The block diagram of the decoder side for the systematic DVB AL-FEC DVB-IPTV 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 DVB-IPTV 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 2.3 outlines the procedures for hybrid decoding.

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

   Lost Packet: X

     Figure 3: Block diagram for the DVB DVB-IPTV 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  DVB-IPTV AL-FEC Specification

   The DVB DVB-IPTV 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.  The performance of these FEC codes has been
   examined in detail in [DVB-A115].

3.1.

2.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 each group of the D source packets whose
   sequence numbers are L apart from each other to generate a total of L
   repair packets.  Due to interleaving, this FEC is effective against
   bursty packet losses up to burst sizes of length L.

   The DVB DVB-IPTV AL-FEC protocol requires the D x L block of the source
   packets protected by the 1-D interleaved FEC code to be wholly
   contained within a single source block of the Raptor code, if both
   FEC layers are used.

   Originally, the DVB DVB-IPTV AL-FEC protocol had adopted the 1-D
   interleaved FEC payload format from [SMPTE2022-1] in
   [ETSI-TS-102-034v1.3.1].  However, some incompatibilities with RTP
   [RFC3550] have been discovered in this specification.  These issues
   have all been addressed in [I-D.ietf-fecframe-interleaved-fec-scheme]
   (For details, refer to Section 1 of
   [I-D.ietf-fecframe-interleaved-fec-scheme]).  Some of the changes
   required by [I-D.ietf-fecframe-interleaved-fec-scheme] are, however,
   not backward compatible with the existing implementations that were
   based on [SMPTE2022-1].

   In a recent liaison from IETF AVT WG to DVB IPI, TM-IPI, it has been
   recommended that DVB IPI TM-IPI defines a new RTP profile for the AL-FEC
   protocol since in the new profile, several of the issues could easily
   be addressed without jeopardizing the compliance to RTP [RFC3550].

   At the writing of this document, it was not clear whether or not a
   new RTP profile would be defined for the AL-FEC protocol.  DVB TM-IPI
   attempted to address some of the issues in the updated specification
   [DVB-A086r7],
   [DVB-A086r8], however, there are still outstanding issues.  Note that
   [DVB-A086r7]
   [DVB-A086r8] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB TM-IPI
   will exclusively use [DVB-A086r7] [DVB-A086r8] for any future revisions of the DVB
   IPTV Handbook.

   The following is a list of the exceptions that MUST need to be considered
   by an implementation adopting
   [I-D.ietf-fecframe-interleaved-fec-scheme] to be in compliant with
   the DVB-IPTV AL-FEC protocol as specified in
   [DVB-A086r7]. [DVB-A086r8].

   o  SSRC
      In the DVB
      The DVB-IPTV AL-FEC protocol, protocol requires the SSRC fields of the FEC
      packets
      MUST to be set to 0. zero.

      This requirement conflicts with RTP [RFC3550].  Unless signaled
      otherwise, RTP uses random SSRC values with collision detection.
      An explicit SSRC signaling mechanism is currently defined in
      [RFC5576].  It is RECOMMENDED that the DVB AL-FEC protocol uses
      this mechanism
      [RFC5576] and can be used for explicit SSRC signaling. this purpose.

   o  CSRC
      The DVB DVB-IPTV AL-FEC protocol does not support the protection of
      the CSRC entries in the source packets.  Thus, in an
      implementation compliant to DVB-IPTV AL-FEC protocol, the source
      stream MUST
      NOT must not have any CSRC entries in its packets and
      subsequently the CC fields of the source RTP packets MUST will be zero.

      Note that if there are no RTP mixers used in a system running the
      DVB
      DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets
      will be 0 zero and this is no longer an issue.  Thus, if defined,
      the new RTP profile for the DVB-IPTV AL-FEC protocol SHOULD should forbid
      the use of any RTP mixers.

   o  Timestamp
      In the DVB DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC
      packets SHALL be are ignored by the receivers.

   o  Payload Type
      In the DVB
      The DVB-IPTV AL-FEC protocol, protocol sets the PT fields of the FEC packets MUST
      be set
      to 96.

      A static payload type assignment for the base-layer FEC packets is
      outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme].
      If defined, the new RTP profile for the DVB-IPTV AL-FEC protocol MAY
      may assign 96 as the payload type for the base-layer FEC packets.

   In implementations that are based on
   [I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in
   compliant with the DVB-IPTV AL-FEC protocol as specified in
   [ETSI-TS-102-034v1.3.1], all these exceptions MUST must be considered as
   well, however, in this case, the sender does not have to select a
   random initial sequence number for the FEC stream as suggested by
   [RFC3550].

   Note that neither [ETSI-TS-102-034v1.3.1] nor [DVB-A086r7] [DVB-A086r8] implements
   the 1-D interleaved parity code as specified in
   [I-D.ietf-fecframe-interleaved-fec-scheme].  Thus, the payload format
   registered in [I-D.ietf-fecframe-interleaved-fec-scheme] MUST NOT must not be
   used by the implementations that are compliant with the
   [ETSI-TS-102-034v1.3.1] or [DVB-A086r7] [DVB-A086r8] specification.

3.2.

2.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 source data.
   Due to the fountain property of the Raptor code, multiple enhancement
   layers may also be specified, if needed.

   The details of the Raptor code are provided in
   [I-D.ietf-fecframe-raptor].  The RTP payload format for Raptor FEC is
   specified in [I-D.watson-fecframe-rtp-raptor].

   It is important to note that the DVB DVB-IPTV AL-FEC protocol in the
   latest specification [DVB-A086r7] [DVB-A086r8] allows only RTP-over-UDP
   encapsulation for the enhancement-layer FEC stream.  The initial
   specification [ETSI-TS-102-034v1.3.1] exclusively permits UDP-only
   encapsulation for the enhancement-layer FEC stream.

   When SDP is used for signaling, the transport protocol identifier
   permits to distinguish whether an RTP-over-UDP or UDP-only
   encapsulation is used.  In case of any other signaling framework, the
   differentiation of the protocol for the enhancement-layer stream is
   achieved either explicitly through a protocol identifier or
   implicitly by the version number of the DVB IPTV Handbook.  If none
   of the above signaling is provided, the receiver shall concur from
   the packet size of the repair packets if RTP-over-UDP or UDP-only
   encapsulation is used.

3.3.

2.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-034v1.3.1] and [DVB-A086r7].

4. [DVB-A086r8].

3.  Session Description Protocol (SDP) Signaling

   This section provides an SDP [RFC4566] example for [DVB-A086r7]. [DVB-A086r8].  The
   example uses the FEC grouping semantics [RFC4756]. [I-D.ietf-mmusic-rfc4756bis].

   In the 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 code as well as another FEC repair stream (mid:R2) that is
   produced by the Raptor FEC code.  We form one FEC group with the
   "a=group:FEC
   "a=group:FEC-XR S1 R1 R2" line.  The source and repair streams are
   sent to the same port on different multicast groups.  The source, base-
   layer
   base-layer FEC and enhancement-layer FEC streams are all encapsulated
   in RTP.

   Due to the exceptions described in Section 3.1, 2.1, a [DVB-A086r7]- [DVB-A086r8]-
   compliant implementation MUST NOT must not use the RTP payload format defined
   in [I-D.ietf-fecframe-interleaved-fec-scheme].  Instead, it may use
   the payload format that has been registered by DVB IPI TM-IPI for
   [ETSI-TS-102-034v1.3.1].

        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.example.com
        s=DVB
        s=DVB-IPTV AL-FEC Example
        t=0 0
        a=group:FEC
        a=group:FEC-XR S1 R1 R2
        m=video 30000 RTP/AVP 100
        c=IN IP4 233.252.0.1/127
        a=rtpmap:100 MP2T/90000
        a=mid:S1
        m=application 30000 RTP/AVP 96
        c=IN IP4 233.252.0.2/127
        a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000
        a=mid:R1
        m=application 30000 RTP/AVP 111
        c=IN IP4 233.252.0.3/127
        a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000
        a=mid:R2

   Note that in the example above, the payload type has been chosen as
   96 for the base-layer FEC stream and there is no "a=fmtp:" line to
   specify the format parameters.  Due to the lack of the format
   parameters,
   parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn
   the FEC parameters from the SDP description.  This severely limits the ability of using multiple
   FEC streams that are generated with different settings.

5.

4.  Security Considerations

   There are no security considerations in this document.

6.

5.  IANA Considerations

   There are no IANA considerations in this document.

7.

6.  Acknowledgments

   This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. [DVB-A086r8].
   Thus, the authors would like to thank the editors of
   [ETSI-TS-102-034v1.3.1] and [DVB-A086r7].

8. [DVB-A086r8].  The authors also would
   like to thank those who reviewed earlier versions of this document.

7.  References

8.1.

7.1.  Normative References

   [ETSI-TS-102-034v1.3.1]
              ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB
              Services over IP Based Networks", October 2007.

   [DVB-A086r7]

   [DVB-A086r8]
              DVB Document A086 Rev. 7 8 (Draft ETSI TS 102 034 V1.4.1),
              "Transport of MPEG 2 TS Based DVB Services over IP Based
              Networks", September 2008. July 2009.

   [I-D.ietf-fecframe-interleaved-fec-scheme]
              Begen, A., "RTP Payload Format for 1-D Interleaved Parity
              FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work
              in progress), May 2009.

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

   [I-D.watson-fecframe-rtp-raptor]
              Watson, M., "RTP Payload Format for Raptor FEC",
              draft-watson-fecframe-rtp-raptor-00 (work in progress),
              October 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.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

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

   [RFC4756]  Li,

   [I-D.ietf-mmusic-rfc4756bis]
              Begen, A., "Forward Error Correction Grouping Semantics in
              Session Description  Protocol", RFC 4756, November 2006.

8.2.
              draft-ietf-mmusic-rfc4756bis-02 (work in progress),
              April 2009.

7.2.  Informative References

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

   [SMPTE2022-1]
              SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
              Video/Audio Transport over IP Networks", 2007.

Authors' Addresses

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

   Email:  abegen@cisco.com

   Thomas Stockhammer
   Nomor Research
   Brecherspitzstrasse 8
   Munich,   81541
   Germany

   Email:  stockhammer@nomor.de