From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6683.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc6683.txt (limited to 'doc/rfc/rfc6683.txt') diff --git a/doc/rfc/rfc6683.txt b/doc/rfc/rfc6683.txt new file mode 100644 index 0000000..061e598 --- /dev/null +++ b/doc/rfc/rfc6683.txt @@ -0,0 +1,619 @@ + + + + + + +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, . + + [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] + -- cgit v1.2.3