FEC Framework A. Begen Internet-Draft Cisco Systems Intended status: Informational T. Stockhammer Expires:
March 2,July 31, 2009 Digital Fountain August 29, 2008January 27, 2009 DVB Application-Layer Hybrid FEC Protection draft-ietf-fecframe-dvb-al-fec-00draft-ietf-fecframe-dvb-al-fec-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the 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 March 2,July 31, 2009. Copyright Notice Copyright (C) The(c) 2009 IETF Trust (2008).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. 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 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 . . . . . . . . . . . . . . . . . . 57 3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 68 4. Session Description Protocol (SDP) Signaling . . . . . . . . . 68 5. Status of DVB AL-FEC Specification . . . . . . . . . . . . . . 7 6.Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8.9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9.10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1.10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2.10 8.2. Informative References . . . . . . . . . . . . . . . . . . 811 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 1011 1. Introduction In 2007, the Digital Video Broadcasting (DVB) consortium published a technical specification [ETSI-TS-102-034][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-034][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, DVB updated the specification in a new revision that has been published as a DVB Bluebook [DVB-A086r7] and serves as draft ETSI TS-102-034v1.4.1 until the final ETSI publication (expected in early 2009). Among others, some updates and modifications to the AL-FEC protocol have been made. The DVB 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 the DVB AL-FEC protocol, the decoding support for the base- layerbase-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 explainsnot modified in any way during the FEC encoding process. The normative DVB AL-FEC protocol by providing references to the two FEC codes used as part of the AL-FEC protocol. This documentconsiders protection of single-sequencesingle- sequence source RTP flows only. The DVB AL-FEC protocolsource can protectbe any type of sourcemedia such as audio, video, text or application. However, in the AL-FEC protocol, the source stream can only be an MPEG-2 transport stream. The FEC data at each layer isare 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 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 RTPstreams. 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. +--------------+ +--+ +--+ +--+ +--+ --> | 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. +--------------+ +--+ 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. The performance of these FEC codes has been examined in detail in [DVB-A115]. 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,Due to interleaving, this FEC is effective against bursty packet losses up to burst sizes of length L. The DVB AL-FEC protocol requires the D x L block of the source packets protected by one or morethe 1-D interleaved FEC packets SHALLcode to be wholly contained within a single source block of the Raptor code. Further detailscode, if both FEC layers are used. Originally, the DVB 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, it has been recommended that DVB 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 attempted to address some of the issues in the updated specification [DVB-A086r7], however, there are still outstanding issues. Note that [DVB-A086r7] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB will exclusively use [DVB-A086r7] for any future revisions of the DVB IPTV Handbook. The following is a list of the exceptions that MUST be considered by an implementation adopting [I-D.ietf-fecframe-interleaved-fec-scheme] to be in compliant with the AL-FEC protocol as specified in [DVB-A086r7]. o SSRC In the DVB AL-FEC protocol, the SSRC fields of the FEC packets MUST be set to 0. 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 [I-D.ietf-mmusic-sdp-source-attributes]. It is RECOMMENDED that the DVB AL-FEC protocol uses this mechanism for explicit SSRC signaling. o CSRC The DVB AL-FEC protocol does not support the protection of the CSRC entries in the source packets. Thus, the source stream MUST NOT have any CSRC entries in its packets and the CC fields of the source RTP packets MUST be zero. Note that if there are no RTP mixers used in a system running the DVB AL-FEC protocol, the CC field of the source RTP packets will be 0 and this is no longer an issue. Thus, if defined, the new RTP profile for the AL-FEC protocol SHOULD forbid the use of any RTP mixers. o Timestamp In the DVB AL-FEC protocol, the timestamp fields of the FEC packets SHALL be ignored by the receivers. o Payload Type In the DVB AL-FEC protocol, 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 AL-FEC protocol 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 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 [DVB-A086r7] 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 be used by the implementations that are provided in [I-D.begen-fecframe-interleaved-fec-scheme].compliant with the [ETSI-TS-102-034v1.3.1] or [DVB-A086r7] specification. 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 asource 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.watson-fecframe-raptor].[I-D.ietf-fecframe-raptor]. The performances of both the 1-D interleaved parity code andRTP payload format for Raptor code have been examinedFEC is specified in detail[I-D.watson-fecframe-rtp-raptor]. It is important to note that the DVB AL-FEC protocol in [DVB-A115].the latest specification [DVB-A086r7] 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. 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].[ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 4. Session Description Protocol (SDP) Signaling This section provides an SDP [RFC4566] example. Thisexample for [DVB-A086r7]. The example uses the FEC grouping semantics [RFC4756]. In thisthe 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 schemecode as well as another FEC repair stream (mid:R2) that is produced by the Raptor FEC scheme.code. 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 defined for Raptorsource, base- layer FEC yet. Once theyand enhancement-layer FEC streams are defined,all encapsulated in RTP. Due to the "a=fmtp" forexceptions described in Section 3.1, a [DVB-A086r7]- compliant implementation MUST NOT use the second repair stream will be updated accordingly.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 for [ETSI-TS-102-034v1.3.1]. 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 188.8.131.52/127 a=rtpmap:100 MP2T/90000 a=mid:S1 m=application 30000 RTP/AVP 11096 c=IN IP4 184.108.40.206/127 a=rtpmap:110 1d-interleaved-parityfec/90000 a=fmtp:110 L:5; D:10; repair-window: 200000a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 a=mid:R1 m=application 30000 RTP/AVP 111 c=IN IP4 220.127.116.11/12718.104.22.168/127 a=rtpmap:111 raptor-fec/90000 a=fmtp:111 ss-fssi=qwe123; repair-window: 200000vnd.dvb.iptv.alfec-enhancement/90000 a=mid:R2 5. Status of DVB AL-FEC Specification AtNote that in the time of writing this document,example above, the payload type has been chosen as 96 for the base-layer FEC stream and there were scheduled updates inis no "a=fmtp:" line to specify the DVB AL-FEC specification. Some partsformat parameters. Due to the lack of these updates will be based onthe [I-D.begen-fecframe-interleaved-fec-scheme] and [I-D.watson-fecframe-raptor]. Further updates (if necessary) informat parameters, it is not possible to learn the AL-FEC specification may be published by DVB. 6.FEC parameters from the SDP description. This severely limits the ability of using multiple FEC streams that are generated with different settings. 5. Security Considerations TheThere are no security considerations in this document. 7.6. IANA Considerations TheThere are no IANA considerations in this document. 8.7. Acknowledgments This document is based on [ETSI-TS-102-034].[ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. Thus, the authors would like to thank the editors of [ETSI-TS-102-034]. 9. References 9.1. Normative References [I-D.begen-fecframe-interleaved-fec-scheme][ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. 8. References 8.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 Document A086 Rev. 7 (Draft ETSI TS 102 034 V1.4.1), "Transport of MPEG 2 TS Based DVB Services over IP Based Networks", September 2008. [I-D.ietf-fecframe-interleaved-fec-scheme] Begen, A., "1-D"RTP Payload Format for 1-D Interleaved Parity FEC Scheme for FEC Framework", draft-begen-fecframe-interleaved-fec-scheme-00FEC", draft-ietf-fecframe-interleaved-fec-scheme-01 (work in progress), JulyOctober 2008. [I-D.watson-fecframe-raptor][I-D.ietf-fecframe-raptor] Watson, M., "Raptor FEC Schemes for FECFRAME", draft-watson-fecframe-raptor-00draft-ietf-fecframe-raptor-00 (work in progress), JulyOctober 2008. [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. [I-D.ietf-mmusic-sdp-source-attributes] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work in progress), October 2008. [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. 22.214.171.124. 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. [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: email@example.com Thomas Stockhammer Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 USA Email: firstname.lastname@example.org 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 email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).