draft-ietf-fecframe-dvb-al-fec-04.txt   rfc6683.txt 
FEC Framework A. Begen Internet Engineering Task Force (IETF) A. Begen
Internet-Draft Cisco Request for Comments: 6683 Cisco
Intended status: Informational T. Stockhammer Category: Informational T. Stockhammer
Expires: June 18, 2010 Nomor Research ISSN: 2070-1721 Nomor Research
December 15, 2009 August 2012
Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV)
Protection Application-Layer Hybrid Forward Error Correction (FEC) Protection
draft-ietf-fecframe-dvb-al-fec-04
Abstract Abstract
The Annex E of the Digital Video Broadcasting (DVB)-IPTV technical Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical
specification defines an optional Application-layer Forward Error specification defines an optional Application-Layer Forward Error
Correction (AL-FEC) protocol to protect the streaming media carried Correction (AL-FEC) protocol to protect the streaming media
over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers
FEC protection. The first (base) layer is based on the 1-D for FEC protection. The first (base) layer is based on the 1-D
interleaved parity code. The second (enhancement) layer is based on interleaved parity code. The second (enhancement) layer is based on
the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC
protocol offers a good protection against both bursty and random protocol offers good protection against both bursty and random packet
packet losses at a cost of decent complexity. This document losses at a cost of decent complexity. This document describes how
describes how one can implement the DVB-IPTV AL-FEC protocol by using one can implement the DVB-IPTV AL-FEC protocol by using the 1-D
the 1-D interleaved parity code and Raptor code that have already interleaved parity code and Raptor code that have already been
been specified in separate documents. specified in separate documents.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on June 18, 2010. 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.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DVB-IPTV AL-FEC Specification . . . . . . . . . . . . . . . . 5 2. DVB-IPTV AL-FEC Specification . . . . . . . . . . . . . . . . 5
2.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7 2.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7
2.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8 2.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 7
3. Session Description Protocol (SDP) Signaling . . . . . . . . . 8 3. Session Description Protocol (SDP) Signaling . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the
Digital Video Broadcasting (DVB) consortium published a technical Digital Video Broadcasting (DVB) consortium published a technical
specification [ETSI-TS-102-034v1.3.1] through European specification [ETSI-TS-102-034v1.3.1] through the European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI).
[ETSI-TS-102-034v1.3.1] covers several areas related to the [ETSI-TS-102-034v1.3.1] covers several areas related to the
transmission of MPEG2 transport stream-based services over IP transmission of MPEG2 transport stream-based services over IP
networks. networks.
The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol for
for Application-layer Forward Error Correction (AL-FEC) to protect Application-Layer Forward Error Correction (AL-FEC) to protect the
the streaming media for DVB-IP services carried over RTP [RFC3550] streaming media for DVB-IP services transported using RTP [RFC3550].
transport. In 2009, DVB updated the specification in a new revision In 2009, DVB updated the specification in a new revision that is
that is available as [ETSI-TS-102-034v1.4.1]. Among others, some available as [ETSI-TS-102-034v1.4.1]. Among others, some updates and
updates and modifications to the AL-FEC protocol have been made. modifications to the AL-FEC protocol have been made. This document
This document describes how one can implement the DVB-IPTV AL-FEC describes how one can implement the DVB-IPTV AL-FEC protocol by using
protocol by using the 1-D interleaved parity code the 1-D interleaved parity code [RFC6015] and Raptor code
[I-D.ietf-fecframe-interleaved-fec-scheme] and Raptor code specifications [RFC6681] [RFC6682].
specifications [I-D.ietf-fecframe-raptor],
[I-D.watson-fecframe-rtp-raptor].
The DVB-IPTV AL-FEC protocol uses two layers for protection: a base 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 layer that is produced by the 1-D interleaved parity code (also
simply referred to as parity code in the remainder of this document), simply referred to as "parity code" in the remainder of this
and an enhancement layer that is produced by the Raptor code. document), and an enhancement layer that is produced by the Raptor
Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the 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 base-layer FEC is mandatory while the
decoding support for the enhancement-layer FEC is optional. Both the decoding support for the enhancement-layer FEC is optional. Both the
interleaved parity code and the Raptor code are systematic FEC codes, interleaved parity code and the Raptor code are systematic FEC codes,
meaning that source packets are not modified in any way during the meaning that source packets are not modified in any way during the
FEC encoding process. FEC encoding process.
The DVB-IPTV AL-FEC protocol considers protection of single-sequence The DVB-IPTV AL-FEC protocol considers protection of single-sequence
source RTP flows only. In the AL-FEC protocol, the source stream can 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 only be an MPEG-2 transport stream. The FEC data at each layer are
generated based on some configuration information, which also generated based on some configuration information, which also
skipping to change at page 4, line 6 skipping to change at page 3, line 33
Description Protocol (SDP) [RFC4566]. Description Protocol (SDP) [RFC4566].
In DVB-IPTV 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-IPTV AL- The block diagram of the encoder side for the systematic DVB-IPTV
FEC protection is sketched in Figure 1. Here, the source packets are AL-FEC protection is described in Figure 1. Here, the source packets
fed into the parity encoder to produce the parity repair 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 source packets may also be fed to the Raptor encoder to produce
the Raptor repair packets. Source packets as well as the repair the Raptor repair packets. Source packets as well as the repair
packets 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 | +==+ +==+ +==+
skipping to change at page 4, line 33 skipping to change at page 4, line 25
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-IPTV 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-IPTV AL- The block diagram of the decoder side for the systematic DVB-IPTV
FEC protection is sketched in Figure 2. This is a Minimum AL-FEC protection is described in Figure 2. This is a minimum
Performance Decoder since the receiver only supports decoding the performance decoder since the receiver only supports decoding the
base-layer repair packets. If there is a loss among the source base-layer repair packets. If there is a loss among the source
packets, the parity decoder attempts to recover the missing source packets, the parity decoder attempts to recover the missing source
packets by 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-IPTV 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 2.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-IPTV AL-FEC enhanced decoder Figure 3: Block Diagram for the DVB-IPTV AL-FEC Enhanced Decoder
2. DVB-IPTV AL-FEC Specification 2. DVB-IPTV AL-FEC Specification
The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection: 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 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].
2.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 each group of D 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 a total of L sequence numbers are L apart from each other to generate a total of L
repair packets. Due to interleaving, this FEC is effective against repair packets. Due to interleaving, this FEC is effective against
bursty packet losses up to burst sizes of length L. bursty packet losses up to burst sizes of length L.
The DVB-IPTV AL-FEC protocol requires the D x L block of the source The DVB-IPTV AL-FEC protocol requires that the D x L block of the
packets protected by the 1-D interleaved FEC code to be wholly source packets protected by the 1-D interleaved FEC code 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-IPTV AL-FEC protocol had adopted the 1-D Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D
interleaved FEC payload format from [SMPTE2022-1] in interleaved FEC payload format from [SMPTE2022-1] in
[ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP [ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP
[RFC3550] have been discovered in this specification. These issues [RFC3550] have been discovered in this specification. These issues
have all been addressed in [I-D.ietf-fecframe-interleaved-fec-scheme] have all been addressed in [RFC6015] (for details, refer to Section 1
(For details, refer to Section 1 of of [RFC6015]). Some of the changes required by [RFC6015] are,
[I-D.ietf-fecframe-interleaved-fec-scheme]). Some of the changes however, not backward compatible with the existing implementations
required by [I-D.ietf-fecframe-interleaved-fec-scheme] are, however, that were based on [SMPTE2022-1].
not backward compatible with the existing implementations that were
based on [SMPTE2022-1].
In a recent liaison from IETF AVT WG to DVB TM-IPI, it has been In a recent liaison statement from the IETF AVT WG to DVB TM-IPI, it
recommended that DVB TM-IPI defines a new RTP profile for the AL-FEC has been recommended that DVB TM-IPI define a new RTP profile for the
protocol since in the new profile, several of the issues could easily AL-FEC protocol since in the new profile, several of the issues could
be addressed without jeopardizing the compliance to RTP [RFC3550]. easily 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 TM-IPI 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
[ETSI-TS-102-034v1.4.1], however, there are still outstanding issues. [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 The following is a list of the exceptions that need to be considered
by an implementation adopting by an implementation adopting [RFC6015] to be compliant with the DVB-
[I-D.ietf-fecframe-interleaved-fec-scheme] to be in compliant with IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1].
the DVB-IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1].
o SSRC o SSRC (synchronization source)
The DVB-IPTV AL-FEC protocol requires the SSRC fields of the FEC The DVB-IPTV AL-FEC protocol requires that the SSRC fields of the
packets to be set to zero. FEC packets 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] and can be used for this purpose. [RFC5576] and can be used for this purpose.
o CSRC o CSRC (contributing source)
The DVB-IPTV AL-FEC protocol does not support the protection of The DVB-IPTV AL-FEC protocol does not support the protection of
the CSRC entries in the source packets. Thus, in an the CSRC entries in the source packets. Thus, in an
implementation compliant to DVB-IPTV AL-FEC protocol, the source implementation compliant to DVB-IPTV AL-FEC protocol, the source
stream must not have any CSRC entries in its packets and stream must not have any CSRC entries in its packets, and
subsequently the CC fields of the source RTP packets will be zero. 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-IPTV AL-FEC protocol, the CC field of the source RTP packets 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, 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 new RTP profile for the DVB-IPTV AL-FEC protocol should forbid
the use of any RTP mixers. the use of any RTP mixers.
o Timestamp o Timestamp
In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC
packets are ignored by the receivers. packets are ignored by the receivers.
o Payload Type o Payload Type
The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets
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 [RFC6015]. If defined, the new RTP profile
If defined, the new RTP profile for the DVB-IPTV AL-FEC protocol for the DVB-IPTV AL-FEC protocol may assign 96 as the payload type
may assign 96 as the payload type for the base-layer FEC packets. for the base-layer FEC packets.
In implementations that are based on In implementations that are based on [RFC6015] and are willing to be
[I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in
compliant with the DVB-IPTV 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 [ETSI-TS-102-034v1.4.1] 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 implements the 1-D interleaved parity code as specified in [RFC6015].
[I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format Thus, the payload format registered in [RFC6015] must not be used by
registered in [I-D.ietf-fecframe-interleaved-fec-scheme] must not be the implementations that are compliant with the
used by the implementations that are compliant with the
[ETSI-TS-102-034v1.3.1] or [ETSI-TS-102-034v1.4.1] specification. [ETSI-TS-102-034v1.3.1] or [ETSI-TS-102-034v1.4.1] specification.
2.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 [RFC6681]. The FEC
[I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is scheme for the enhancement layer SHALL be the Raptor FEC scheme for a
specified in [I-D.watson-fecframe-rtp-raptor]. 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 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 latest specification [ETSI-TS-102-034v1.4.1] allows both UDP-only and
RTP-over-UDP encapsulations for the enhancement-layer FEC stream. RTP-over-UDP encapsulations for the enhancement-layer FEC stream.
The initial specification [ETSI-TS-102-034v1.3.1] exclusively permits The initial specification [ETSI-TS-102-034v1.3.1] exclusively permits
UDP-only encapsulation for the enhancement-layer FEC stream. UDP-only 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 indicates whether an RTP-over-UDP or UDP-only encapsulation is used.
encapsulation is used. In case of any other signaling framework, the In case of any other signaling framework, the differentiation of the
differentiation of the protocol for the enhancement-layer stream is protocol for the enhancement-layer stream is achieved either
achieved either explicitly through a protocol identifier or explicitly through a protocol identifier or implicitly by the version
implicitly by the version number of the DVB IPTV Handbook. If none number of the DVB IPTV Handbook. If none of the above signaling is
of the above signaling is provided, the receiver shall concur from provided, the receiver shall concur from the packet size of the
the packet size of the repair packets if RTP-over-UDP or UDP-only repair packets if RTP-over-UDP or UDP-only encapsulation is used.
encapsulation is used.
2.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.
2. Enhancement-layer (Raptor) Decoding: If there are still missing 2. Enhancement-layer (Raptor) Decoding: If there are still missing
source packets after the first step, the repair packets that are source packets after the first step, the repair packets that are
skipping to change at page 8, line 47 skipping to change at page 8, line 24
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.4.1]. in Annex E.5.2 of [ETSI-TS-102-034v1.4.1].
3. Session Description Protocol (SDP) Signaling 3. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example for This section provides an SDP [RFC4566] example for
[ETSI-TS-102-034v1.4.1]. The example uses the FEC grouping semantics [ETSI-TS-102-034v1.4.1]. The example uses the FEC grouping semantics
[I-D.ietf-mmusic-rfc4756bis]. [RFC5956].
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-XR S1 R1 R2" line. The source and repair streams are "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, sent to the same port on different multicast groups. The source,
base-layer FEC and enhancement-layer FEC streams are all encapsulated base-layer FEC, and enhancement-layer FEC streams are all
in RTP. encapsulated in RTP.
Due to the exceptions described in Section 2.1, a Due to the exceptions described in Section 2.1, a
[ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP [ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP
payload format defined in [I-D.ietf-fecframe-interleaved-fec-scheme]. payload format defined in [RFC6015]. Instead, it may use the payload
Instead, it may use the payload format that has been registered by format that has been registered by DVB TM-IPI for
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-IPTV AL-FEC Example s=DVB-IPTV AL-FEC Example
t=0 0 t=0 0
a=group:FEC-XR S1 R1 R2 a=group:FEC-FR 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
skipping to change at page 10, line 5 skipping to change at page 9, line 34
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 for "vnd.dvb.iptv.alfec-base", it is not possible to learn parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn
the FEC parameters from the SDP description. the FEC parameters from the SDP description.
4. Security Considerations 4. Security Considerations
This specification adds no new security considerations to the DVB- This specification adds no new security considerations to the DVB-
IPTV AL-FEC protocol. IPTV AL-FEC protocol.
5. IANA Considerations 5. Acknowledgments
There are no IANA considerations in this document.
6. Acknowledgments
This document is based on [ETSI-TS-102-034v1.3.1] and 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 [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 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 authors also would like to thank those who reviewed earlier versions
of this document. of this document.
7. References 6. References
7.1. Normative References 6.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.
[ETSI-TS-102-034v1.4.1] [ETSI-TS-102-034v1.4.1]
ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB ETSI TS 102 034 V1.4.1, "Transport of MPEG 2 TS Based DVB
Services over IP Based Networks", August 2009. Services over IP Based Networks", August 2009.
[I-D.ietf-fecframe-interleaved-fec-scheme] [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity
Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, October 2010.
FEC", draft-ietf-fecframe-interleaved-fec-scheme-05 (work
in progress), May 2009.
[I-D.ietf-fecframe-raptor] [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC
Watson, M., "Raptor FEC Schemes for FECFRAME", Schemes for FECFRAME", RFC RFC6681, August 2012.
draft-ietf-fecframe-raptor-01 (work in progress),
July 2009.
[I-D.watson-fecframe-rtp-raptor] [RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload
Watson, M., "RTP Payload Format for Raptor FEC", Format for Raptor Forward Error Correction (FEC)",
draft-watson-fecframe-rtp-raptor-00 (work in progress), RFC 6682, August 2012.
October 2008.
[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.
[I-D.ietf-mmusic-rfc4756bis] [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956,
Session Description Protocol", September 2010.
draft-ietf-mmusic-rfc4756bis-05 (work in progress),
October 2009.
7.2. Informative References 6.2. Informative References
[DVB-A115] [DVB-A115]
Available at: http://www.dvb.org/technology/standards/ "DVB Application Layer FEC Evaluations (DVB Document
a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer A115)", May 2007, <http://www.dvb.org/technology/
FEC Evaluations (DVB Document A115)", May 2007. standards/a115.tm3783.AL-FEC_Evaluation.pdf>.
[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.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Cisco
170 West Tasman Drive 181 Bay Street
San Jose, CA 95134 Toronto, ON M5J 2T3
USA Canada
Email: abegen@cisco.com EMail: abegen@cisco.com
Thomas Stockhammer Thomas Stockhammer
Nomor Research Nomor Research
Brecherspitzstrasse 8 Brecherspitzstrasse 8
Munich, 81541 Munich, 81541
Germany Germany
Email: stockhammer@nomor.de EMail: stockhammer@nomor.de
 End of changes. 57 change blocks. 
160 lines changed or deleted 132 lines changed or added

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