FEC Framework A. Begen
Internet-Draft Cisco Systems
Intended status: Informational T. Stockhammer
Expires: January 8, 2009 Digital Fountain
July 7, 2008
DVB Application-Layer Hybrid FEC Protection
draft-begen-fecframe-dvb-al-fec-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 January 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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. Since both of these codes have already been specified in
Begen & Stockhammer Expires January 8, 2009 [Page 1]
Internet-Draft DVB AL-FEC Scheme July 2008
separate documents, the current document does not define the details
of these codes but provides the references to the respective
specifications. 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.
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 . . . . . . . . . . . . . . . . . . 6
3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 6
4. Session Description Protocol (SDP) Signaling . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Begen & Stockhammer Expires January 8, 2009 [Page 2]
Internet-Draft DVB AL-FEC Scheme July 2008
1. Introduction
In 2007, the Digital Video Broadcasting (DVB) consortium published a
technical specification [DVB-AL-FEC] 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 [DVB-AL-FEC] defines an optional protocol for
Application-layer FEC (AL-FEC) protection of streaming media for
DVB-IP services carried over RTP [RFC3550] transport. The 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
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 always sent as
part of the transport.
This document briefly explains the DVB AL-FEC protocol by providing
references to the two FEC schemes used as part of the AL-FEC
protocol. This document considers protection of single sequence RTP
flows only.
The DVB AL-FEC protocol can protect any type of source media such as
audio, video, text or application. The FEC data at each layer is
generated by an instance of the FEC Framework
[I-D.ietf-fecframe-framework], which is configured by the FEC
Framework Configuration Information. The configuration information
and the information contained in the Payload IDs of the source and
repair packets establish the exact associations and relationships
between the source and repair packets. This document shows how the
FEC Framework Configuration Information may be communicated out-of-
band in Session Description Protocol (SDP) [RFC4566].
The FEC Framework requires the source packets to be transmitted in a
source flow and the repair packets to be transmitted in one or more
repair flows. In other words, the sender MUST NOT mix source and
repair packets in a single flow. 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
Begen & Stockhammer Expires January 8, 2009 [Page 3]
Internet-Draft DVB AL-FEC Scheme July 2008
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
Begen & Stockhammer Expires January 8, 2009 [Page 4]
Internet-Draft DVB AL-FEC Scheme July 2008
On the other hand, if the receiver supports decoding both the base-
layer and enhancement-layer repair packets, a combined (hybrid)
decoding approach is adopted 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 +--+ --> | 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.
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, the D
x L block of the source packets protected by one or more FEC packets
SHALL be wholly contained within a single source block of the Raptor
code. Further details of the 1-D interleaved parity code are
provided in [I-D.begen-fecframe-interleaved-fec-scheme].
Begen & Stockhammer Expires January 8, 2009 [Page 5]
Internet-Draft DVB AL-FEC Scheme July 2008
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 a source data.
Due to the fountain property of the Raptor code, multiple enhancement
layers may also be specified.
The details of the Raptor code are provided in
[I-D.watson-fecframe-raptor]. The performances of both the 1-D
interleaved parity code and Raptor code have been examined in detail
in [DVB-A115].
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 step 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 E5.2 of [DVB-AL-FEC].
4. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example. This example uses
the SDP elements for FEC Framework, which were introduced in
[I-D.ietf-fecframe-sdp-elements], and the FEC grouping semantics
[RFC4756].
Begen & Stockhammer Expires January 8, 2009 [Page 6]
Internet-Draft DVB AL-FEC Scheme July 2008
Editor's note: No FEC Encoding IDs have been registered with IANA
for the 1-D interleaved parity FEC scheme and Raptor FEC scheme. For
illustrative purposes, in the example below, FEC Encoding IDs of 10
and 11 will respectively be used.
In this 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 scheme as well as another FEC repair stream (mid:R2) that is
produced by the Raptor FEC scheme. 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.
v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
s=DVB AL-FEC Example
t=0 0
a=group:FEC S1 R1 R2
m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fec-repair-flow: encoding-id=10; ss-fssi=L:5 D:10
a=repair-window: 200
a=mid:R1
m=application 30000 RTP/AVP 111
c=IN IP4 224.1.3.1/127
a=rtpmap:111 raptor-fec/90000
a=fec-repair-flow: encoding-id=11; ss-fssi=qwe123
a=repair-window: 200
a=mid:R2
5. Security Considerations
The are no security considerations in this document. For the general
security considerations related to the use of FEC, refer to
[I-D.ietf-fecframe-framework].
6. IANA Considerations
The are no IANA considerations in this document.
Begen & Stockhammer Expires January 8, 2009 [Page 7]
Internet-Draft DVB AL-FEC Scheme July 2008
7. Acknowledgments
This document is largely based on [DVB-AL-FEC]. Thus, the authors
would like to thank the editors of [DVB-AL-FEC].
8. References
8.1. Normative References
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-01 (work in progress),
November 2007.
[I-D.ietf-fecframe-sdp-elements]
Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-00 (work in progress),
February 2008.
[I-D.begen-fecframe-interleaved-fec-scheme]
Begen, A., "1-D Interleaved Parity FEC Scheme for FEC
Framework", draft-begen-fecframe-interleaved-fec-scheme-00
(work in progress), July 2008.
[I-D.watson-fecframe-raptor]
Watson, M., "Raptor FEC Schemes for FECFRAME",
draft-watson-fecframe-raptor-00 (work in progress),
July 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.
[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.
8.2. Informative References
[DVB-AL-FEC]
DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1),
"Transport of MPEG 2 Transport Stream (TS) Based DVB
Begen & Stockhammer Expires January 8, 2009 [Page 8]
Internet-Draft DVB AL-FEC Scheme July 2008
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.
Authors' Addresses
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Thomas Stockhammer
Digital Fountain
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
USA
Email: stockhammer@digitalfountain.com
Begen & Stockhammer Expires January 8, 2009 [Page 9]
Internet-Draft DVB AL-FEC Scheme July 2008
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Begen & Stockhammer Expires January 8, 2009 [Page 10]