GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6683

Internet Engineering Task Force (IETF) A. Begen Request for Comments: 6683 Cisco Category: Informational T. Stockhammer ISSN: 2070-1721 Nomor Research

                                                           August 2012

Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV)

 Application-Layer Hybrid Forward Error Correction (FEC) Protection

Abstract

 Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical
 specification defines an optional Application-Layer Forward Error
 Correction (AL-FEC) protocol to protect the streaming media
 transported using RTP.  The 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-IPTV AL-FEC
 protocol offers good protection against both bursty and random packet
 losses at a cost of decent complexity.  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.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6683.

Begen & Stockhammer Informational [Page 1] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

Copyright Notice

 Copyright (c) 2012 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  DVB-IPTV AL-FEC Specification  . . . . . . . . . . . . . . . .  5
   2.1.  Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . .  5
   2.2.  Enhancement-Layer FEC  . . . . . . . . . . . . . . . . . .  7
   2.3.  Hybrid Decoding Procedures . . . . . . . . . . . . . . . .  7
 3.  Session Description Protocol (SDP) Signaling . . . . . . . . .  8
 4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
 5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
 6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
   6.2.  Informative References . . . . . . . . . . . . . . . . . . 10

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 the European
 Telecommunications Standards Institute (ETSI).
 [ETSI-TS-102-034v1.3.1] covers several areas related to the
 transmission of MPEG2 transport stream-based services over IP
 networks.
 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 transported using RTP [RFC3550].
 In 2009, DVB updated the specification in a new revision that is
 available as [ETSI-TS-102-034v1.4.1].  Among others, some updates and
 modifications to the AL-FEC protocol have been made.  This document
 describes how one can implement the DVB-IPTV AL-FEC protocol by using
 the 1-D interleaved parity code [RFC6015] and Raptor code
 specifications [RFC6681] [RFC6682].

Begen & Stockhammer Informational [Page 2] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

 The DVB-IPTV AL-FEC protocol uses two layers for protection:  a base
 layer that is produced by the 1-D interleaved parity 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-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 DVB-IPTV AL-FEC protocol considers protection of single-sequence
 source RTP flows only.  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-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-IPTV
 AL-FEC protection is described 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 Informational [Page 3] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

                            +--------------+
 +--+  +--+  +--+  +--+ --> |  Systematic  | -> +--+  +--+  +--+  +--+
 +--+  +--+  +--+  +--+     |FEC Protection|    +--+  +--+  +--+  +--+
                            +--------------+
                            |    Parity    | -> +==+  +==+  +==+
                            |    Encoder   |    +==+  +==+  +==+
                            +--------------+
                            |    Raptor    | -> +~~+  +~~+
                            |    Encoder   |    +~~+  +~~+
                            +--------------+
 Source Packet: +--+
                +--+
 Base-layer Repair Packet: +==+
                           +==+
 Enhancement-layer Repair Packet: +~~+
                                  +~~+
        Figure 1: Block Diagram for the DVB-IPTV AL-FEC Encoder
 The block diagram of the decoder side for the systematic DVB-IPTV
 AL-FEC protection is described 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-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 2.3 outlines the procedures for hybrid decoding.

Begen & Stockhammer Informational [Page 4] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

                            +--------------+
 +--+   X     X     X   --> |  Systematic  | -> +--+  +--+  +--+  +--+
 +--+                       |FEC Protection|    +--+  +--+  +--+  +--+
                            +--------------+
       +==+  +==+  +==+ --> |    Parity    |
       +==+  +==+  +==+     |    Decoder   |
                            +--------------+
             +~~+  +~~+ --> |    Raptor    |
             +~~+  +~~+     |    Decoder   |
                            +--------------+
 Lost Packet: X
   Figure 3: Block Diagram for the DVB-IPTV AL-FEC Enhanced Decoder

2. DVB-IPTV AL-FEC Specification

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

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 each group of 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-IPTV AL-FEC protocol requires that the D x L block of the
 source packets protected by the 1-D interleaved FEC code be wholly
 contained within a single source block of the Raptor code, if both
 FEC layers are used.
 Originally, the 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 [RFC6015] (for details, refer to Section 1
 of [RFC6015]).  Some of the changes required by [RFC6015] are,
 however, not backward compatible with the existing implementations
 that were based on [SMPTE2022-1].
 In a recent liaison statement from the IETF AVT WG to DVB TM-IPI, it
 has been recommended that DVB TM-IPI define a new RTP profile for the

Begen & Stockhammer Informational [Page 5] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

 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
 [ETSI-TS-102-034v1.4.1]; however, there are still outstanding issues.
 The following is a list of the exceptions that need to be considered
 by an implementation adopting [RFC6015] to be compliant with the DVB-
 IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1].
 o  SSRC (synchronization source)
    The DVB-IPTV AL-FEC protocol requires that the SSRC fields of the
    FEC packets be set to 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] and can be used for this purpose.
 o  CSRC (contributing source)
    The 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 have any CSRC entries in its packets, and
    subsequently the CC fields of the source RTP packets will be zero.
    Note that if there are no RTP mixers used in a system running the
    DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets
    will be zero and this is no longer an issue.  Thus, if defined,
    the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid
    the use of any RTP mixers.
 o  Timestamp
    In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC
    packets are ignored by the receivers.
 o  Payload Type
    The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets
    to 96.
    A static payload type assignment for the base-layer FEC packets is
    outside the scope of [RFC6015].  If defined, the new RTP profile
    for the DVB-IPTV AL-FEC protocol may assign 96 as the payload type
    for the base-layer FEC packets.

Begen & Stockhammer Informational [Page 6] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

 In implementations that are based on [RFC6015] and are willing to be
 compliant with the DVB-IPTV AL-FEC protocol as specified in
 [ETSI-TS-102-034v1.3.1], all these exceptions 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 [ETSI-TS-102-034v1.4.1]
 implements the 1-D interleaved parity code as specified in [RFC6015].
 Thus, the payload format registered in [RFC6015] must not be used by
 the implementations that are compliant with the
 [ETSI-TS-102-034v1.3.1] or [ETSI-TS-102-034v1.4.1] specification.

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 [RFC6681].  The FEC
 scheme for the enhancement layer SHALL be the Raptor FEC scheme for a
 Single Sequenced Flow with FEC encoding ID 5.  The RTP payload format
 for Raptor FEC is specified in [RFC6682].
 It is important to note that the DVB-IPTV AL-FEC protocol in the
 latest specification [ETSI-TS-102-034v1.4.1] allows both UDP-only and
 RTP-over-UDP encapsulations 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
 indicates 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.

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:

Begen & Stockhammer Informational [Page 7] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

 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 Annex E.5.2 of [ETSI-TS-102-034v1.4.1].

3. Session Description Protocol (SDP) Signaling

 This section provides an SDP [RFC4566] example for
 [ETSI-TS-102-034v1.4.1].  The example uses the FEC grouping semantics
 [RFC5956].
 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-FR S1 R1 R2" line.  The source and repair streams are
 sent to the same port on different multicast groups.  The source,
 base-layer FEC, and enhancement-layer FEC streams are all
 encapsulated in RTP.
 Due to the exceptions described in Section 2.1, a
 [ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP
 payload format defined in [RFC6015].  Instead, it may use the payload
 format that has been registered by DVB TM-IPI for
 [ETSI-TS-102-034v1.3.1].

Begen & Stockhammer Informational [Page 8] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

      v=0
      o=ali 1122334455 1122334466 IN IP4 fec.example.com
      s=DVB-IPTV AL-FEC Example
      t=0 0
      a=group:FEC-FR 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 for "vnd.dvb.iptv.alfec-base", it is not possible to learn
 the FEC parameters from the SDP description.

4. Security Considerations

 This specification adds no new security considerations to the DVB-
 IPTV AL-FEC protocol.

5. Acknowledgments

 This document is based on [ETSI-TS-102-034v1.3.1] and
 [ETSI-TS-102-034v1.4.1].  Thus, the authors would like to thank the
 editors of [ETSI-TS-102-034v1.3.1] and [ETSI-TS-102-034v1.4.1].  The
 authors also would like to thank those who reviewed earlier versions
 of this document.

Begen & Stockhammer Informational [Page 9] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

6. References

6.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.
 [ETSI-TS-102-034v1.4.1]
            ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB
            Services over IP Based Networks", August 2009.
 [RFC6015]  Begen, A., "RTP Payload Format for 1-D Interleaved Parity
            Forward Error Correction (FEC)", RFC 6015, October 2010.
 [RFC6681]  Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC
            Schemes for FECFRAME", RFC RFC6681, August 2012.
 [RFC6682]  Watson, M., Stockhammer, T., and M. Luby, "RTP Payload
            Format for Raptor Forward Error Correction (FEC)",
            RFC 6682, August 2012.
 [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.
 [RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
            the Session Description Protocol", RFC 5956,
            September 2010.

6.2. Informative References

 [DVB-A115]
            "DVB Application Layer FEC Evaluations (DVB Document
            A115)", May 2007, <http://www.dvb.org/technology/
            standards/a115.tm3783.AL-FEC_Evaluation.pdf>.
 [SMPTE2022-1]
            SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
            Video/Audio Transport over IP Networks", 2007.

Begen & Stockhammer Informational [Page 10] RFC 6683 Guidelines for DVB AL-FEC Protocol August 2012

Authors' Addresses

 Ali Begen
 Cisco
 181 Bay Street
 Toronto, ON  M5J 2T3
 Canada
 EMail:  abegen@cisco.com
 Thomas Stockhammer
 Nomor Research
 Brecherspitzstrasse 8
 Munich,   81541
 Germany
 EMail:  stockhammer@nomor.de

Begen & Stockhammer Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6683.txt · Last modified: 2012/08/14 16:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki