draft-ietf-fecframe-interleaved-fec-scheme-00.txt   draft-ietf-fecframe-interleaved-fec-scheme-01.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track August 29, 2008 Intended status: Standards Track October 27, 2008
Expires: March 2, 2009 Expires: April 30, 2009
RTP Payload Format for 1-D Interleaved Parity FEC RTP Payload Format for 1-D Interleaved Parity FEC
draft-ietf-fecframe-interleaved-fec-scheme-00 draft-ietf-fecframe-interleaved-fec-scheme-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 April 30, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a new RTP payload format for the Forward Error This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP. The 1-D interleaved parity from a source media encapsulated in RTP. The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are code is a systematic code, where a number of repair symbols are
generated from a set of source symbols and sent in a repair flow generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols. The separate from the source flow that carries the source symbols. The
1-D interleaved parity code offers a good protection against bursty 1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of decent complexity. The new payload format packet losses at a cost of decent complexity. The new payload format
defined in this document is compatible with and used as a part of the defined in this document is used as a part of the DVB Application-
DVB Application-layer FEC Specification. layer FEC Specification.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Overhead Computation . . . . . . . . . . . . . . . . . . . 8 1.2. Overhead Computation . . . . . . . . . . . . . . . . . . . 8
1.3. Relation to Existing Specifications . . . . . . . . . . . 8 1.3. Relation to Existing Specifications . . . . . . . . . . . 8
1.3.1. RFC 2733 and RFC 3009 . . . . . . . . . . . . . . . . 8 1.3.1. RFC 2733 and RFC 3009 . . . . . . . . . . . . . . . . 8
1.3.2. SMPTE 2022-1 . . . . . . . . . . . . . . . . . . . . . 8 1.3.2. SMPTE 2022-1 . . . . . . . . . . . . . . . . . . . . . 8
1.3.3. ETSI TS 102 034 . . . . . . . . . . . . . . . . . . . 9 1.3.3. ETSI TS 102 034 . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 2, line 46 skipping to change at page 2, line 46
6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 20 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 20
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 22 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 22
6.3.1. Associating the Source and Repair Packets . . . . . . 23 6.3.1. Associating the Source and Repair Packets . . . . . . 23
6.3.2. Recovering the RTP Header and Payload . . . . . . . . 23 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 23
7. Session Description Protocol (SDP) Signaling . . . . . . . . . 25 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 25
8. Congestion Control Considerations . . . . . . . . . . . . . . 25 8. Congestion Control Considerations . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 26 12.1. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 26
12.2. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
This document extends the Forward Error Correction (FEC) header This document extends the Forward Error Correction (FEC) header
defined in [RFC2733] and uses this new FEC header for the FEC that is defined in [RFC2733] and uses this new FEC header for the FEC that is
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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-034] defines an optional protocol for
Application-layer FEC (AL-FEC) protection of streaming media for Application-layer FEC (AL-FEC) protection of streaming media for
DVB-IP services carried over RTP [RFC3550] transport. AL-FEC DVB-IP services carried over RTP [RFC3550] transport. AL-FEC
protocol uses two layers for protection: a base layer that is protocol uses two layers for protection: a base layer that is
produced by a packet-based interleaved parity code, and an produced by a packet-based interleaved parity code, and an
enhancement layer that is produced by a Raptor code. While the use enhancement layer that is produced by a Raptor code. While the use
of the enhancement layer is optional, the use of the base layer is of the enhancement layer is optional, the use of the base layer is
mandatory wherever AL-FEC is used. The DVB AL-FEC protocol is also mandatory wherever AL-FEC is used. The DVB AL-FEC protocol is also
described in [I-D.begen-fecframe-dvb-al-fec]. described in [I-D.ietf-fecframe-dvb-al-fec].
The interleaved parity code that is used in the base layer is a The interleaved parity code that is used in the base layer is a
subset of [SMPTE2022-1]. In particular, AL-FEC base layer uses the subset of [SMPTE2022-1]. In particular, AL-FEC base layer uses only
1-D interleaved FEC protection only from [SMPTE2022-1]. The new RTP the 1-D interleaved FEC protection from [SMPTE2022-1]. The new RTP
payload format that is defined and registered in this document is payload format that is defined and registered in this document (with
compatible with and used as the AL-FEC base layer. some exceptions listed in [I-D.ietf-fecframe-dvb-al-fec]) is used as
the AL-FEC base layer.
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. Definitions, Notations and Abbreviations 3. Definitions, Notations and Abbreviations
The definitions, notations and abbreviations commonly used in this The definitions, notations and abbreviations commonly used in this
skipping to change at page 12, line 34 skipping to change at page 12, line 34
Section 5 for details). According to [RFC3550], an RTP receiver Section 5 for details). According to [RFC3550], an RTP receiver
that cannot recognize a payload type must discard it. This that cannot recognize a payload type must discard it. This
provides backward compatibility. The FEC mechanisms can then be provides backward compatibility. The FEC mechanisms can then be
used in a multicast group with mixed FEC-capable and non-FEC- used in a multicast group with mixed FEC-capable and non-FEC-
capable receivers. If a non-FEC-capable receiver receives a capable receivers. If a non-FEC-capable receiver receives a
repair packet, it will not recognize the payload type, and hence, repair packet, it will not recognize the payload type, and hence,
discards the repair packet. discards the repair packet.
o Sequence Number (SN): The sequence number has the standard o Sequence Number (SN): The sequence number has the standard
definition. It MUST be one higher than the sequence number in the definition. It MUST be one higher than the sequence number in the
previously transmitted repair packet. previously transmitted repair packet. The initial value of the
sequence number SHOULD be random (unpredictable) [RFC3550].
o Timestamp (TS): The timestamp MUST be set to the timestamp of the o Timestamp (TS): The timestamp SHALL be set to a time
source packet whose sequence number is the lowest among the source corresponding to the repair packet's transmission time. Note that
packets protected by this repair packet. the timestamp value has no use in the actual FEC protection
process and is usually useful for jitter calculations.
o Synchronization Source (SSRC): The SSRC value SHALL be randomly o Synchronization Source (SSRC): The SSRC value SHALL be randomly
assigned as suggested by [RFC3550]. This allows the sender to assigned as suggested by [RFC3550]. This allows the sender to
multiplex the source and repair flows on the same port, or multiplex the source and repair flows on the same port, or
multiplex multiple repair flows on a single port. The repair multiplex multiple repair flows on a single port. The repair
flows SHOULD use the RTCP CNAME field to associate themselves with flows SHOULD use the RTCP CNAME field to associate themselves with
the source flow. Note that due to the randomness of the SSRC the source flow. Note that due to the randomness of the SSRC
assignments, there is a possibility of SSRC collision. In such assignments, there is a possibility of SSRC collision. In such
cases, the collisions MUST be resolved as described in [RFC3550]. cases, the collisions MUST be resolved as described in [RFC3550].
skipping to change at page 26, line 34 skipping to change at page 26, line 34
11. Acknowledgments 11. Acknowledgments
A major part of this document is borrowed from [RFC2733] and A major part of this document is borrowed from [RFC2733] and
[SMPTE2022-1]. Thus, the author would like to thank the authors and [SMPTE2022-1]. Thus, the author would like to thank the authors and
editors of these earlier specifications. The author also thanks editors of these earlier specifications. The author also thanks
Colin Perkins for his constructive suggestions for this document. Colin Perkins for his constructive suggestions for this document.
12. Change Log 12. Change Log
12.1. draft-ietf-fecframe-interleaved-fec-scheme-00 12.1. draft-ietf-fecframe-interleaved-fec-scheme-01
The following are the major changes compared to version 00:
o The timestamp field definition has changed.
12.2. draft-ietf-fecframe-interleaved-fec-scheme-00
This is the initial version, which is based on an earlier individual This is the initial version, which is based on an earlier individual
submission. The following are the major changes compared to that submission. The following are the major changes compared to that
document: document:
o Per the discussion in the WG, references to the FEC Framework have o Per the discussion in the WG, references to the FEC Framework have
been removed and the document has been turned into a pure RTP been removed and the document has been turned into a pure RTP
payload format specification. payload format specification.
o A new section is added for congestion control considerations. o A new section is added for congestion control considerations.
skipping to change at page 27, line 30 skipping to change at page 27, line 38
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003. Payload Formats", RFC 3555, July 2003.
13.2. Informative References 13.2. Informative References
[I-D.begen-fecframe-dvb-al-fec] [I-D.ietf-fecframe-dvb-al-fec]
Begen, A. and T. Stockhammer, "DVB Application-Layer Begen, A. and T. Stockhammer, "DVB Application-Layer
Hybrid FEC Protection", draft-begen-fecframe-dvb-al-fec-00 Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-00
(work in progress), July 2008. (work in progress), August 2008.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, for Generic Forward Error Correction", RFC 2733,
December 1999. December 1999.
[RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of
parityfec MIME types", RFC 3009, November 2000. parityfec MIME types", RFC 3009, November 2000.
[ETSI-TS-102-034] [ETSI-TS-102-034]
DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1), DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1),
 End of changes. 12 change blocks. 
20 lines changed or deleted 30 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/