draft-ietf-fecframe-dvb-al-fec-02.txt   draft-ietf-fecframe-dvb-al-fec-03.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational T. Stockhammer Intended status: Informational T. Stockhammer
Expires: February 12, 2010 Nomor Research Expires: March 20, 2010 Nomor Research
August 11, 2009 September 16, 2009
DVB Application-Layer Hybrid FEC Protection DVB-IPTV Application-Layer Hybrid FEC Protection
draft-ietf-fecframe-dvb-al-fec-02 draft-ietf-fecframe-dvb-al-fec-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 12, 2010. This Internet-Draft will expire on March 20, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes the Application-layer Forward Error The Annex E of the DVB-IPTV technical specification defines an
Correction (FEC) protocol that was developed by the Digital Video optional Application-layer Forward Error Correction (AL-FEC) protocol
Broadcasting (DVB) consortium for the protection of media streams to protect the streaming media carried over RTP transport. The DVB-
over IP networks. The DVB AL-FEC protocol uses two layers for FEC IPTV AL-FEC protocol uses two layers for FEC protection. The first
protection. The first (base) layer is based on the 1-D interleaved (base) layer is based on the 1-D interleaved parity code. The second
parity code. The second (enhancement) layer is based on the Raptor (enhancement) layer is based on the Raptor code. By offering a
code. By offering a layered approach, the DVB AL-FEC offers a good layered approach, the DVB-IPTV AL-FEC protocol offers a good
protection against both bursty and random packet losses at a cost of protection against both bursty and random packet losses at a cost of
decent complexity. The 1-D interleaved parity code and Raptor code decent complexity. This document describes how one can implement the
have already been specified in separate documents and the current DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and
document normatively references these specifications. Raptor code that have already been specified in separate documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. DVB-IPTV AL-FEC Specification . . . . . . . . . . . . . . . . 5
3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5 2.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7
3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7 2.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8
3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8 3. Session Description Protocol (SDP) Signaling . . . . . . . . . 8
4. Session Description Protocol (SDP) Signaling . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In 2007, the Digital Video Broadcasting (DVB) consortium published a In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the
technical specification [ETSI-TS-102-034v1.3.1] through European Digital Video Broadcasting (DVB) consortium published a technical
specification [ETSI-TS-102-034v1.3.1] through European
Telecommunications Standards Institute (ETSI). This specification Telecommunications Standards Institute (ETSI). This specification
covers several areas related to the transmission of MPEG2 transport covers several areas related to the transmission of MPEG2 transport
stream-based services over IP networks. stream-based services over IP networks.
The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol
for Application-layer Forward Error Correction (AL-FEC) to protect for Application-layer Forward Error Correction (AL-FEC) to protect
the streaming media for DVB-IP services carried over RTP [RFC3550] the streaming media for DVB-IP services carried over RTP [RFC3550]
transport. In 2008, DVB updated the specification in a new revision transport. In 2009, DVB updated the specification in a new revision
that has been published as a DVB Bluebook [DVB-A086r7] and serves as that has been published as a DVB Bluebook [DVB-A086r8] and serves as
draft ETSI TS-102-034v1.4.1 until the final ETSI publication draft ETSI TS-102-034v1.4.1 until the final ETSI publication
(expected in early 2009). Among others, some updates and (expected late 2009). Among others, some updates and modifications
modifications to the AL-FEC protocol have been made. to the AL-FEC protocol have been made.
The DVB AL-FEC protocol uses two layers for protection: a base layer The DVB-IPTV AL-FEC protocol uses two layers for protection: a base
that is produced by the 1-D interleaved parity code, and an layer that is produced by the 1-D interleaved parity code (also
enhancement layer that is produced by the Raptor code. Whenever a simply referred to as parity code in the remainder of this document),
receiver supports the DVB AL-FEC protocol, the decoding support for and an enhancement layer that is produced by the Raptor code.
the base-layer FEC is mandatory while the decoding support for the Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the
enhancement-layer FEC is optional. Both the interleaved parity code decoding support for the base-layer FEC is mandatory while the
and the Raptor code are systematic FEC codes, meaning that source decoding support for the enhancement-layer FEC is optional. Both the
packets are not modified in any way during the FEC encoding process. 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 normative DVB AL-FEC protocol considers protection of single- The normative DVB-IPTV AL-FEC protocol considers protection of
sequence source RTP flows only. The source can be any type of media single-sequence source RTP flows only. In the AL-FEC protocol, the
such as audio, video, text or application. However, in the AL-FEC source stream can only be an MPEG-2 transport stream. The FEC data
protocol, the source stream can only be an MPEG-2 transport stream. at each layer are generated based on some configuration information,
The FEC data at each layer are generated based on some configuration which also determines the exact associations and relationships
information, which also determines the exact associations and between the source and repair packets. This document shows how this
relationships between the source and repair packets. This document configuration may be communicated out-of-band in the Session
shows how this configuration may be communicated out-of-band in the Description Protocol (SDP) [RFC4566].
Session Description Protocol (SDP) [RFC4566].
In DVB AL-FEC, the source packets are carried in the source RTP 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 stream and the generated FEC repair packets at each layer are carried
in separate streams. At the receiver side, if all of the source in separate streams. At the receiver side, if all of the source
packets are successfully received, there is no need for FEC recovery packets are successfully received, there is no need for FEC recovery
and the repair packets may be discarded. However, if there are and the repair packets may be discarded. However, if there are
missing source packets, the repair packets can be used to recover the missing source packets, the repair packets can be used to recover the
missing information. missing information.
The block diagram of the encoder side for the systematic DVB AL-FEC The block diagram of the encoder side for the systematic DVB-IPTV AL-
protection is sketched in Figure 1. Here, the source packets are fed FEC protection is sketched in Figure 1. Here, the source packets are
into the parity encoder to produce the parity repair packets. The fed into the parity encoder to produce the parity repair packets.
source packets may also be fed to the Raptor encoder to produce the The source packets may also be fed to the Raptor encoder to produce
Raptor repair packets. Source packets as well as the repair packets the Raptor repair packets. Source packets as well as the repair
are then sent to the receiver(s) over an IP network. packets are then sent to the receiver(s) over an IP network.
+--------------+ +--------------+
+--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+
+--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+
+--------------+ +--------------+
| Parity | -> +==+ +==+ +==+ | Parity | -> +==+ +==+ +==+
| Encoder | +==+ +==+ +==+ | Encoder | +==+ +==+ +==+
+--------------+ +--------------+
| Raptor | -> +~~+ +~~+ | Raptor | -> +~~+ +~~+
| Encoder | +~~+ +~~+ | Encoder | +~~+ +~~+
skipping to change at page 4, line 27 skipping to change at page 4, line 29
Source Packet: +--+ Source Packet: +--+
+--+ +--+
Base-layer Repair Packet: +==+ Base-layer Repair Packet: +==+
+==+ +==+
Enhancement-layer Repair Packet: +~~+ Enhancement-layer Repair Packet: +~~+
+~~+ +~~+
Figure 1: Block diagram for the DVB AL-FEC encoder Figure 1: Block diagram for the DVB-IPTV AL-FEC encoder
The block diagram of the decoder side for the systematic DVB AL-FEC The block diagram of the decoder side for the systematic DVB-IPTV AL-
protection is sketched in Figure 2. This is a Minimum Performance FEC protection is sketched in Figure 2. This is a Minimum
Decoder since the receiver only supports decoding the base-layer Performance Decoder since the receiver only supports decoding the
repair packets. If there is a loss among the source packets, the base-layer repair packets. If there is a loss among the source
parity decoder attempts to recover the missing source packets by packets, the parity decoder attempts to recover the missing source
using the base-layer repair packets. packets by using the base-layer repair packets.
+--------------+ +--------------+
+--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+
+--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+
+--------------+ +--------------+
+==+ +==+ +==+ --> | Parity | +==+ +==+ +==+ --> | Parity |
+==+ +==+ +==+ | Decoder | +==+ +==+ +==+ | Decoder |
+--------------+ +--------------+
Lost Packet: X Lost Packet: X
Figure 2: Block diagram for the DVB AL-FEC minimum performance Figure 2: Block diagram for the DVB-IPTV AL-FEC minimum performance
decoder decoder
On the other hand, if the receiver supports decoding both the base- On the other hand, if the receiver supports decoding both the base-
layer and enhancement-layer repair packets, a combined (hybrid) layer and enhancement-layer repair packets, a combined (hybrid)
decoding approach is employed to improve the recovery rate of the decoding approach is employed to improve the recovery rate of the
lost packets. In this case, the decoder is called an Enhanced lost packets. In this case, the decoder is called an Enhanced
Decoder. Section 3.3 outlines the procedures for hybrid decoding. Decoder. Section 2.3 outlines the procedures for hybrid decoding.
+--------------+ +--------------+
+--+ X X X --> | Systematic | -> +--+ +--+ +--+ +--+ +--+ X X X --> | Systematic | -> +--+ +--+ +--+ +--+
+--+ |FEC Protection| +--+ +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+
+--------------+ +--------------+
+==+ +==+ +==+ --> | Parity | +==+ +==+ +==+ --> | Parity |
+==+ +==+ +==+ | Decoder | +==+ +==+ +==+ | Decoder |
+--------------+ +--------------+
+~~+ +~~+ --> | Raptor | +~~+ +~~+ --> | Raptor |
+~~+ +~~+ | Decoder | +~~+ +~~+ | Decoder |
+--------------+ +--------------+
Lost Packet: X Lost Packet: X
Figure 3: Block diagram for the DVB AL-FEC enhanced decoder Figure 3: Block diagram for the DVB-IPTV 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 2. DVB-IPTV AL-FEC Specification
The DVB AL-FEC protocol comprises two layers of FEC protection: 1-D The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection:
interleaved parity FEC for the base layer and Raptor FEC for the 1-D interleaved parity FEC for the base layer and Raptor FEC for the
enhancement layer. The performance of these FEC codes has been enhancement layer. The performance of these FEC codes has been
examined in detail in [DVB-A115]. examined in detail in [DVB-A115].
3.1. Base-Layer FEC 2.1. Base-Layer FEC
The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 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, 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 the XOR operation is applied to each group of D source packets whose
sequence numbers are L apart from each other to generate L repair sequence numbers are L apart from each other to generate a total of L
packets. Due to interleaving, this FEC is effective against bursty repair packets. Due to interleaving, this FEC is effective against
packet losses up to burst sizes of length L. bursty packet losses up to burst sizes of length L.
The DVB AL-FEC protocol requires the D x L block of the source The DVB-IPTV AL-FEC protocol requires the D x L block of the source
packets protected by the 1-D interleaved FEC code to be wholly packets protected by the 1-D interleaved FEC code to be wholly
contained within a single source block of the Raptor code, if both contained within a single source block of the Raptor code, if both
FEC layers are used. FEC layers are used.
Originally, the DVB AL-FEC protocol had adopted the 1-D interleaved Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D
FEC payload format from [SMPTE2022-1] in [ETSI-TS-102-034v1.3.1]. interleaved FEC payload format from [SMPTE2022-1] in
However, some incompatibilities with RTP [RFC3550] have been [ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP
discovered in this specification. These issues have all been [RFC3550] have been discovered in this specification. These issues
addressed in [I-D.ietf-fecframe-interleaved-fec-scheme] (For details, have all been addressed in [I-D.ietf-fecframe-interleaved-fec-scheme]
refer to Section 1 of [I-D.ietf-fecframe-interleaved-fec-scheme]). (For details, refer to Section 1 of
Some of the changes required by [I-D.ietf-fecframe-interleaved-fec-scheme]). Some of the changes
[I-D.ietf-fecframe-interleaved-fec-scheme] are, however, not backward required by [I-D.ietf-fecframe-interleaved-fec-scheme] are, however,
compatible with the existing implementations that were based on not backward compatible with the existing implementations that were
[SMPTE2022-1]. based on [SMPTE2022-1].
In a recent liaison from IETF AVT WG to DVB IPI, it has been In a recent liaison from IETF AVT WG to DVB TM-IPI, it has been
recommended that DVB IPI defines a new RTP profile for the AL-FEC recommended that DVB TM-IPI defines a new RTP profile for the AL-FEC
protocol since in the new profile, several of the issues could easily protocol since in the new profile, several of the issues could easily
be addressed without jeopardizing the compliance to RTP [RFC3550]. be addressed without jeopardizing the compliance to RTP [RFC3550].
At the writing of this document, it was not clear whether or not a 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 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 attempted to address some of the issues in the updated specification
[DVB-A086r7], however, there are still outstanding issues. Note that [DVB-A086r8], however, there are still outstanding issues. Note that
[DVB-A086r7] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB will [DVB-A086r8] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB TM-IPI
exclusively use [DVB-A086r7] for any future revisions of the DVB IPTV will exclusively use [DVB-A086r8] for any future revisions of the DVB
Handbook. IPTV Handbook.
The following is a list of the exceptions that MUST be considered by The following is a list of the exceptions that need to be considered
an implementation adopting [I-D.ietf-fecframe-interleaved-fec-scheme] by an implementation adopting
to be in compliant with the AL-FEC protocol as specified in [I-D.ietf-fecframe-interleaved-fec-scheme] to be in compliant with
[DVB-A086r7]. the DVB-IPTV AL-FEC protocol as specified in [DVB-A086r8].
o SSRC o SSRC
In the DVB AL-FEC protocol, the SSRC fields of the FEC packets The DVB-IPTV AL-FEC protocol requires the SSRC fields of the FEC
MUST be set to 0. packets to be set to zero.
This requirement conflicts with RTP [RFC3550]. Unless signaled This requirement conflicts with RTP [RFC3550]. Unless signaled
otherwise, RTP uses random SSRC values with collision detection. otherwise, RTP uses random SSRC values with collision detection.
An explicit SSRC signaling mechanism is currently defined in An explicit SSRC signaling mechanism is currently defined in
[RFC5576]. It is RECOMMENDED that the DVB AL-FEC protocol uses [RFC5576] and can be used for this purpose.
this mechanism for explicit SSRC signaling.
o CSRC o CSRC
The DVB AL-FEC protocol does not support the protection of the The DVB-IPTV AL-FEC protocol does not support the protection of
CSRC entries in the source packets. Thus, the source stream MUST the CSRC entries in the source packets. Thus, in an
NOT have any CSRC entries in its packets and the CC fields of the implementation compliant to DVB-IPTV AL-FEC protocol, the source
source RTP packets MUST be zero. 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 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 DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets
be 0 and this is no longer an issue. Thus, if defined, the new will be zero and this is no longer an issue. Thus, if defined,
RTP profile for the AL-FEC protocol SHOULD forbid the use of any the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid
RTP mixers. the use of any RTP mixers.
o Timestamp o Timestamp
In the DVB AL-FEC protocol, the timestamp fields of the FEC In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC
packets SHALL be ignored by the receivers. packets are ignored by the receivers.
o Payload Type o Payload Type
In the DVB AL-FEC protocol, the PT fields of the FEC packets MUST The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets
be set to 96. to 96.
A static payload type assignment for the base-layer FEC packets is A static payload type assignment for the base-layer FEC packets is
outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme]. outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme].
If defined, the new RTP profile for the AL-FEC protocol MAY assign If defined, the new RTP profile for the DVB-IPTV AL-FEC protocol
96 as the payload type for the base-layer FEC packets. may assign 96 as the payload type for the base-layer FEC packets.
In implementations that are based on In implementations that are based on
[I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in [I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in
compliant with the AL-FEC protocol as specified in compliant with the DVB-IPTV AL-FEC protocol as specified in
[ETSI-TS-102-034v1.3.1], all these exceptions MUST be considered as [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 well, however, in this case, the sender does not have to select a
random initial sequence number for the FEC stream as suggested by random initial sequence number for the FEC stream as suggested by
[RFC3550]. [RFC3550].
Note that neither [ETSI-TS-102-034v1.3.1] nor [DVB-A086r7] implements Note that neither [ETSI-TS-102-034v1.3.1] nor [DVB-A086r8] implements
the 1-D interleaved parity code as specified in the 1-D interleaved parity code as specified in
[I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format [I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format
registered in [I-D.ietf-fecframe-interleaved-fec-scheme] MUST NOT be registered in [I-D.ietf-fecframe-interleaved-fec-scheme] must not be
used by the implementations that are compliant with the used by the implementations that are compliant with the
[ETSI-TS-102-034v1.3.1] or [DVB-A086r7] specification. [ETSI-TS-102-034v1.3.1] or [DVB-A086r8] specification.
3.2. Enhancement-Layer FEC 2.2. Enhancement-Layer FEC
The Raptor code is a fountain code where as many encoding symbols as 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. needed can be generated by the encoder on-the-fly from source data.
Due to the fountain property of the Raptor code, multiple enhancement Due to the fountain property of the Raptor code, multiple enhancement
layers may also be specified, if needed. layers may also be specified, if needed.
The details of the Raptor code are provided in The details of the Raptor code are provided in
[I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is [I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is
specified in [I-D.watson-fecframe-rtp-raptor]. specified in [I-D.watson-fecframe-rtp-raptor].
It is important to note that the DVB AL-FEC protocol in the latest It is important to note that the DVB-IPTV AL-FEC protocol in the
specification [DVB-A086r7] allows only RTP-over-UDP encapsulation for latest specification [DVB-A086r8] allows only RTP-over-UDP
the enhancement-layer FEC stream. The initial specification encapsulation for the enhancement-layer FEC stream. The initial
[ETSI-TS-102-034v1.3.1] exclusively permits UDP-only encapsulation specification [ETSI-TS-102-034v1.3.1] exclusively permits UDP-only
for the enhancement-layer FEC stream. encapsulation for the enhancement-layer FEC stream.
When SDP is used for signaling, the transport protocol identifier When SDP is used for signaling, the transport protocol identifier
permits to distinguish whether an RTP-over-UDP or UDP-only permits to distinguish whether an RTP-over-UDP or UDP-only
encapsulation is used. In case of any other signaling framework, the encapsulation is used. In case of any other signaling framework, the
differentiation of the protocol for the enhancement-layer stream is differentiation of the protocol for the enhancement-layer stream is
achieved either explicitly through a protocol identifier or achieved either explicitly through a protocol identifier or
implicitly by the version number of the DVB IPTV Handbook. If none implicitly by the version number of the DVB IPTV Handbook. If none
of the above signaling is provided, the receiver shall concur from 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 the packet size of the repair packets if RTP-over-UDP or UDP-only
encapsulation is used. encapsulation is used.
3.3. Hybrid Decoding Procedures 2.3. Hybrid Decoding Procedures
The receivers that support receiving and decoding both the base and The receivers that support receiving and decoding both the base and
enhancement-layer FEC perform hybrid decoding to improve the repair enhancement-layer FEC perform hybrid decoding to improve the repair
performance. The following steps may be followed to perform hybrid performance. The following steps may be followed to perform hybrid
decoding: decoding:
1. Base-layer (Parity) Decoding: In this step, the repair packets 1. Base-layer (Parity) Decoding: In this step, the repair packets
that are encoded by the parity encoder are processed as usual to that are encoded by the parity encoder are processed as usual to
repair as many missing source packets as possible. repair as many missing source packets as possible.
skipping to change at page 8, line 42 skipping to change at page 8, line 37
3. Hybrid Decoding: If there are still missing source packets after 3. Hybrid Decoding: If there are still missing source packets after
the second step, the unprocessed base-layer (parity) repair the second step, the unprocessed base-layer (parity) repair
packets are converted to a form in which they can be added to the packets are converted to a form in which they can be added to the
Raptor decoding process. With this additional information, Raptor decoding process. With this additional information,
Raptor decoding may potentially recover any remaining missing Raptor decoding may potentially recover any remaining missing
source packet. source packet.
The procedure that should be followed to benefit from the base-layer The procedure that should be followed to benefit from the base-layer
repair packets in the Raptor decoding process is explained in detail repair packets in the Raptor decoding process is explained in detail
in Section E.5.2 of [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. in Section E.5.2 of [ETSI-TS-102-034v1.3.1] and [DVB-A086r8].
4. Session Description Protocol (SDP) Signaling 3. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example for [DVB-A086r7]. The This section provides an SDP [RFC4566] example for [DVB-A086r8]. The
example uses the FEC grouping semantics [RFC4756]. example uses the FEC grouping semantics [I-D.ietf-mmusic-rfc4756bis].
In the example, we have one source video stream (mid:S1), one FEC 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 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 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 produced by the Raptor FEC code. We form one FEC group with the
"a=group:FEC S1 R1 R2" line. The source and repair streams are sent "a=group:FEC-XR S1 R1 R2" line. The source and repair streams are
to the same port on different multicast groups. The source, base- sent to the same port on different multicast groups. The source,
layer FEC and enhancement-layer FEC streams are all encapsulated in base-layer FEC and enhancement-layer FEC streams are all encapsulated
RTP. in RTP.
Due to the exceptions described in Section 3.1, a [DVB-A086r7]- Due to the exceptions described in Section 2.1, a [DVB-A086r8]-
compliant implementation MUST NOT use the RTP payload format defined compliant implementation must not use the RTP payload format defined
in [I-D.ietf-fecframe-interleaved-fec-scheme]. Instead, it may use in [I-D.ietf-fecframe-interleaved-fec-scheme]. Instead, it may use
the payload format that has been registered by DVB IPI for the payload format that has been registered by DVB TM-IPI for
[ETSI-TS-102-034v1.3.1]. [ETSI-TS-102-034v1.3.1].
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=DVB AL-FEC Example s=DVB-IPTV AL-FEC Example
t=0 0 t=0 0
a=group:FEC S1 R1 R2 a=group:FEC-XR S1 R1 R2
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=mid:S1 a=mid:S1
m=application 30000 RTP/AVP 96 m=application 30000 RTP/AVP 96
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000
a=mid:R1 a=mid:R1
m=application 30000 RTP/AVP 111 m=application 30000 RTP/AVP 111
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000 a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000
a=mid:R2 a=mid:R2
Note that in the example above, the payload type has been chosen as 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 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 specify the format parameters. Due to the lack of the format
parameters, it is not possible to learn the FEC parameters from the parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn
SDP description. This severely limits the ability of using multiple the FEC parameters from the SDP description.
FEC streams that are generated with different settings.
5. Security Considerations 4. Security Considerations
There are no security considerations in this document. There are no security considerations in this document.
6. IANA Considerations 5. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
7. Acknowledgments 6. Acknowledgments
This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r8].
Thus, the authors would like to thank the editors of Thus, the authors would like to thank the editors of
[ETSI-TS-102-034v1.3.1] and [DVB-A086r7]. [ETSI-TS-102-034v1.3.1] and [DVB-A086r8]. The authors also would
like to thank those who reviewed earlier versions of this document.
8. References 7. References
8.1. Normative References 7.1. Normative References
[ETSI-TS-102-034v1.3.1] [ETSI-TS-102-034v1.3.1]
ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB ETSI TS 102 034 V1.3.1, "Transport of MPEG 2 TS Based DVB
Services over IP Based Networks", October 2007. Services over IP Based Networks", October 2007.
[DVB-A086r7] [DVB-A086r8]
DVB Document A086 Rev. 7 (Draft ETSI TS 102 034 V1.4.1), DVB Document A086 Rev. 8 (Draft ETSI TS 102 034 V1.4.1),
"Transport of MPEG 2 TS Based DVB Services over IP Based "Transport of MPEG 2 TS Based DVB Services over IP Based
Networks", September 2008. Networks", July 2009.
[I-D.ietf-fecframe-interleaved-fec-scheme] [I-D.ietf-fecframe-interleaved-fec-scheme]
Begen, A., "RTP Payload Format for 1-D Interleaved Parity Begen, A., "RTP Payload Format for 1-D Interleaved Parity
FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work
in progress), May 2009. in progress), May 2009.
[I-D.ietf-fecframe-raptor] [I-D.ietf-fecframe-raptor]
Watson, M., "Raptor FEC Schemes for FECFRAME", Watson, M., "Raptor FEC Schemes for FECFRAME",
draft-ietf-fecframe-raptor-01 (work in progress), draft-ietf-fecframe-raptor-01 (work in progress),
July 2009. July 2009.
[I-D.watson-fecframe-rtp-raptor] [I-D.watson-fecframe-rtp-raptor]
Watson, M., "RTP Payload Format for Raptor FEC", Watson, M., "RTP Payload Format for Raptor FEC",
draft-watson-fecframe-rtp-raptor-00 (work in progress), draft-watson-fecframe-rtp-raptor-00 (work in progress),
October 2008. 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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [I-D.ietf-mmusic-rfc4756bis]
Session Description Protocol", RFC 4756, November 2006. Begen, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol",
draft-ietf-mmusic-rfc4756bis-02 (work in progress),
April 2009.
8.2. Informative References 7.2. Informative References
[DVB-A115] [DVB-A115]
Available at: http://www.dvb.org/technology/standards/ Available at: http://www.dvb.org/technology/standards/
a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer
FEC Evaluations (DVB Document A115)", May 2007. FEC Evaluations (DVB Document A115)", May 2007.
[SMPTE2022-1] [SMPTE2022-1]
SMPTE 2022-1-2007, "Forward Error Correction for Real-Time SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
Video/Audio Transport over IP Networks", 2007. Video/Audio Transport over IP Networks", 2007.
 End of changes. 63 change blocks. 
165 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/