draft-ietf-fecframe-dvb-al-fec-00.txt   draft-ietf-fecframe-dvb-al-fec-01.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: March 2, 2009 Digital Fountain Expires: July 31, 2009 Digital Fountain
August 29, 2008 January 27, 2009
DVB Application-Layer Hybrid FEC Protection DVB Application-Layer Hybrid FEC Protection
draft-ietf-fecframe-dvb-al-fec-00 draft-ietf-fecframe-dvb-al-fec-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 March 2, 2009. This Internet-Draft will expire on July 31, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 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.
Abstract Abstract
This document describes the Application-layer Forward Error This document describes the Application-layer Forward Error
Correction (FEC) protocol that was developed by the Digital Video Correction (FEC) protocol that was developed by the Digital Video
Broadcasting (DVB) consortium for the protection of media streams Broadcasting (DVB) consortium for the protection of media streams
over IP networks. The DVB AL-FEC protocol uses two layers for FEC 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 protection. The first (base) layer is based on the 1-D interleaved
parity code. The second (enhancement) layer is based on the Raptor parity code. The second (enhancement) layer is based on the Raptor
code. By offering a layered approach, the DVB AL-FEC offers a good code. By offering a layered approach, the DVB AL-FEC offers a good
skipping to change at page 2, line 15 skipping to change at page 2, line 21
decent complexity. The 1-D interleaved parity code and Raptor code decent complexity. The 1-D interleaved parity code and Raptor code
have already been specified in separate documents and the current have already been specified in separate documents and the current
document normatively references these specifications. document normatively references these specifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5 3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5
3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 5 3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 7
3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 6 3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 8
4. Session Description Protocol (SDP) Signaling . . . . . . . . . 6 4. Session Description Protocol (SDP) Signaling . . . . . . . . . 8
5. Status of DVB AL-FEC Specification . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
In 2007, the Digital Video Broadcasting (DVB) consortium published a In 2007, the Digital Video Broadcasting (DVB) consortium published a
technical specification [ETSI-TS-102-034] through European 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-034] defines an optional protocol for The Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol
Application-layer Forward Error Correction (AL-FEC) to protect the for Application-layer Forward Error Correction (AL-FEC) to protect
streaming media for DVB-IP services carried over RTP [RFC3550] the streaming media for DVB-IP services carried over RTP [RFC3550]
transport. The AL-FEC protocol uses two layers for protection: a transport. In 2008, DVB updated the specification in a new revision
base layer that is produced by the 1-D interleaved parity code, and that has been published as a DVB Bluebook [DVB-A086r7] and serves as
an enhancement layer that is produced by the Raptor code. Whenever a draft ETSI TS-102-034v1.4.1 until the final ETSI publication
receiver supports AL-FEC protocol, the decoding support for the base- (expected in early 2009). Among others, some updates and
layer FEC is mandatory while the decoding support for the modifications to the AL-FEC protocol have been made.
The DVB 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 the DVB 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 enhancement-layer FEC is optional. Both the interleaved parity code
and the Raptor code are systematic FEC codes, meaning that source and the Raptor code are systematic FEC codes, meaning that source
packets are always sent as part of the transport. packets are not modified in any way during the FEC encoding process.
This document briefly explains the DVB AL-FEC protocol by providing The normative DVB AL-FEC protocol considers protection of single-
references to the two FEC codes used as part of the AL-FEC protocol. sequence source RTP flows only. The source can be any type of media
This document considers protection of single-sequence RTP flows only. such as audio, video, text or application. However, in the AL-FEC
The DVB AL-FEC protocol can protect any type of source media such as protocol, the source stream can only be an MPEG-2 transport stream.
audio, video, text or application. The FEC data at each layer is The FEC data at each layer are generated based on some configuration
generated based on some configuration information, which also information, which also determines the exact associations and
determines the exact associations and relationships between the relationships between the source and repair packets. This document
source and repair packets. This document shows this configuration shows how this configuration may be communicated out-of-band in the
may be communicated out-of-band in Session Description Protocol (SDP) Session Description Protocol (SDP) [RFC4566].
[RFC4566].
In DVB AL-FEC, the source packets are carried in the source RTP In DVB 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 RTP 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 AL-FEC
protection is sketched in Figure 1. Here, the source packets are fed protection is sketched in Figure 1. Here, the source packets are fed
into the parity encoder to produce the parity repair packets. The 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 packets Raptor repair packets. Source packets as well as the repair packets
skipping to change at page 5, line 30 skipping to change at page 5, line 34
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. DVB AL-FEC Specification 3. DVB AL-FEC Specification
The DVB AL-FEC protocol comprises two layers of FEC protection: 1-D 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 interleaved parity FEC for the base layer and Raptor FEC for the
enhancement layer. enhancement layer. The performance of these FEC codes has been
examined in detail in [DVB-A115].
3.1. Base-Layer FEC 3.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 the group of the 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 L repair
packets. When used in combination with the enhancement layer, the D packets. Due to interleaving, this FEC is effective against bursty
x L block of the source packets protected by one or more FEC packets packet losses up to burst sizes of length L.
SHALL be wholly contained within a single source block of the Raptor
code. Further details of the 1-D interleaved parity code are The DVB AL-FEC protocol requires the D x L block of the source
provided in [I-D.begen-fecframe-interleaved-fec-scheme]. packets protected by the 1-D interleaved FEC code to be wholly
contained within a single source block of the Raptor code, if both
FEC layers are used.
Originally, the DVB 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 [I-D.ietf-fecframe-interleaved-fec-scheme] (For details,
refer to Section 1 of [I-D.ietf-fecframe-interleaved-fec-scheme]).
Some of the changes required by
[I-D.ietf-fecframe-interleaved-fec-scheme] are, however, not backward
compatible with the existing implementations that were based on
[SMPTE2022-1].
In a recent liaison from IETF AVT WG to DVB IPI, it has been
recommended that DVB IPI defines a new RTP profile for the 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
attempted to address some of the issues in the updated specification
[DVB-A086r7], however, there are still outstanding issues. Note that
[DVB-A086r7] does not obsolete [ETSI-TS-102-034v1.3.1] but DVB will
exclusively use [DVB-A086r7] for any future revisions of the DVB IPTV
Handbook.
The following is a list of the exceptions that MUST be considered by
an implementation adopting [I-D.ietf-fecframe-interleaved-fec-scheme]
to be in compliant with the AL-FEC protocol as specified in
[DVB-A086r7].
o SSRC
In the DVB AL-FEC protocol, the SSRC fields of the FEC packets
MUST be set to 0.
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
[I-D.ietf-mmusic-sdp-source-attributes]. It is RECOMMENDED that
the DVB AL-FEC protocol uses this mechanism for explicit SSRC
signaling.
o CSRC
The DVB AL-FEC protocol does not support the protection of the
CSRC entries in the source packets. Thus, the source stream MUST
NOT have any CSRC entries in its packets and the CC fields of the
source RTP packets MUST be zero.
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
be 0 and this is no longer an issue. Thus, if defined, the new
RTP profile for the AL-FEC protocol SHOULD forbid the use of any
RTP mixers.
o Timestamp
In the DVB AL-FEC protocol, the timestamp fields of the FEC
packets SHALL be ignored by the receivers.
o Payload Type
In the DVB AL-FEC protocol, the PT fields of the FEC packets MUST
be set to 96.
A static payload type assignment for the base-layer FEC packets is
outside the scope of [I-D.ietf-fecframe-interleaved-fec-scheme].
If defined, the new RTP profile for the AL-FEC protocol MAY assign
96 as the payload type for the base-layer FEC packets.
In implementations that are based on
[I-D.ietf-fecframe-interleaved-fec-scheme] and are willing to be in
compliant with the 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 [DVB-A086r7] implements
the 1-D interleaved parity code as specified in
[I-D.ietf-fecframe-interleaved-fec-scheme]. Thus, the payload format
registered in [I-D.ietf-fecframe-interleaved-fec-scheme] MUST NOT be
used by the implementations that are compliant with the
[ETSI-TS-102-034v1.3.1] or [DVB-A086r7] specification.
3.2. Enhancement-Layer FEC 3.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 a 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.watson-fecframe-raptor]. The performances of both the 1-D [I-D.ietf-fecframe-raptor]. The RTP payload format for Raptor FEC is
interleaved parity code and Raptor code have been examined in detail specified in [I-D.watson-fecframe-rtp-raptor].
in [DVB-A115].
It is important to note that the DVB AL-FEC protocol in the latest
specification [DVB-A086r7] allows only RTP-over-UDP encapsulation 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
permits to distinguish 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.
3.3. Hybrid Decoding Procedures 3.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
skipping to change at page 6, line 36 skipping to change at page 8, line 43
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-034]. in Section E.5.2 of [ETSI-TS-102-034v1.3.1] and [DVB-A086r7].
4. Session Description Protocol (SDP) Signaling 4. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example. This example uses This section provides an SDP [RFC4566] example for [DVB-A086r7]. The
the FEC grouping semantics [RFC4756]. example uses the FEC grouping semantics [RFC4756].
In this 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 scheme 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 scheme. 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 S1 R1 R2" line. The source and repair streams are sent
to the same port on different multicast groups. The repair window is to the same port on different multicast groups. The source, base-
set to 200 ms. layer FEC and enhancement-layer FEC streams are all encapsulated in
RTP.
Editor's note: The payload-format-specific parameters have not been Due to the exceptions described in Section 3.1, a [DVB-A086r7]-
defined for Raptor FEC yet. Once they are defined, the "a=fmtp" for compliant implementation MUST NOT use the RTP payload format defined
the second repair stream will be updated accordingly. in [I-D.ietf-fecframe-interleaved-fec-scheme]. Instead, it may use
the payload format that has been registered by DVB IPI for
[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 AL-FEC Example
t=0 0 t=0 0
a=group:FEC S1 R1 R2 a=group:FEC S1 R1 R2
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127 c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=mid:S1 a=mid:S1
m=application 30000 RTP/AVP 110 m=application 30000 RTP/AVP 96
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=rtpmap:110 1d-interleaved-parityfec/90000 a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000
a=fmtp:110 L:5; D:10; repair-window: 200000
a=mid:R1 a=mid:R1
m=application 30000 RTP/AVP 111 m=application 30000 RTP/AVP 111
c=IN IP4 224.1.3.1/127 c=IN IP4 224.1.2.2/127
a=rtpmap:111 raptor-fec/90000 a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000
a=fmtp:111 ss-fssi=qwe123; repair-window: 200000
a=mid:R2 a=mid:R2
5. Status of DVB AL-FEC Specification 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, it is not possible to learn the FEC parameters from the
SDP description. This severely limits the ability of using multiple
FEC streams that are generated with different settings.
At the time of writing this document, there were scheduled updates in 5. Security Considerations
the DVB AL-FEC specification. Some parts of these updates will be
based on the [I-D.begen-fecframe-interleaved-fec-scheme] and
[I-D.watson-fecframe-raptor]. Further updates (if necessary) in the
AL-FEC specification may be published by DVB.
6. Security Considerations There are no security considerations in this document.
The are no security considerations in this document. 6. IANA Considerations
7. IANA Considerations There are no IANA considerations in this document.
The are no IANA considerations in this document. 7. Acknowledgments
8. Acknowledgments This document is based on [ETSI-TS-102-034v1.3.1] and [DVB-A086r7].
Thus, the authors would like to thank the editors of
[ETSI-TS-102-034v1.3.1] and [DVB-A086r7].
This document is based on [ETSI-TS-102-034]. Thus, the authors would 8. References
like to thank the editors of [ETSI-TS-102-034].
9. References 8.1. Normative References
9.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.
[I-D.begen-fecframe-interleaved-fec-scheme] [DVB-A086r7]
Begen, A., "1-D Interleaved Parity FEC Scheme for FEC DVB Document A086 Rev. 7 (Draft ETSI TS 102 034 V1.4.1),
Framework", draft-begen-fecframe-interleaved-fec-scheme-00 "Transport of MPEG 2 TS Based DVB Services over IP Based
(work in progress), July 2008. Networks", September 2008.
[I-D.watson-fecframe-raptor] [I-D.ietf-fecframe-interleaved-fec-scheme]
Begen, A., "RTP Payload Format for 1-D Interleaved Parity
FEC", draft-ietf-fecframe-interleaved-fec-scheme-01 (work
in progress), October 2008.
[I-D.ietf-fecframe-raptor]
Watson, M., "Raptor FEC Schemes for FECFRAME", Watson, M., "Raptor FEC Schemes for FECFRAME",
draft-watson-fecframe-raptor-00 (work in progress), draft-ietf-fecframe-raptor-00 (work in progress),
July 2008. October 2008.
[I-D.watson-fecframe-rtp-raptor]
Watson, M., "RTP Payload Format for Raptor FEC",
draft-watson-fecframe-rtp-raptor-00 (work in progress),
October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.
[I-D.ietf-mmusic-sdp-source-attributes]
Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work
in progress), October 2008.
[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 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
9.2. Informative References 8.2. Informative References
[ETSI-TS-102-034]
DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1),
"Transport of MPEG 2 Transport Stream (TS) Based DVB
Services over IP Based Networks", March 2007.
[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]
SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
Video/Audio Transport over IP Networks", 2007.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
Thomas Stockhammer Thomas Stockhammer
Digital Fountain Digital Fountain
39141 Civic Center Drive 39141 Civic Center Drive
Suite 300 Suite 300
Fremont, CA 94538 Fremont, CA 94538
USA USA
Email: stockhammer@digitalfountain.com Email: stockhammer@digitalfountain.com
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).
 End of changes. 41 change blocks. 
97 lines changed or deleted 224 lines changed or added

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