summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6683.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6683.txt')
-rw-r--r--doc/rfc/rfc6683.txt619
1 files changed, 619 insertions, 0 deletions
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, <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]
+