draft-ietf-fecframe-interleaved-fec-scheme-05.txt   draft-ietf-fecframe-interleaved-fec-scheme-06.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco
Intended status: Standards Track May 5, 2009 Intended status: Standards Track December 15, 2009
Expires: November 6, 2009 Expires: June 18, 2010
RTP Payload Format for 1-D Interleaved Parity FEC RTP Payload Format for 1-D Interleaved Parity FEC
draft-ietf-fecframe-interleaved-fec-scheme-05 draft-ietf-fecframe-interleaved-fec-scheme-06
Abstract
This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP. The 1-D interleaved parity
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
separate from the source flow that carries the source symbols. The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of decent complexity. The new payload format
defined in this document is used (with some exceptions) as a part of
the DVB Application-layer FEC specification.
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 32 skipping to change at page 1, line 45
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 November 6, 2009. This Internet-Draft will expire on June 18, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document defines a new RTP payload format for the Forward Error described in the BSD License.
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP. The 1-D interleaved parity
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
separate from the source flow that carries the source symbols. The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of decent complexity. The new payload format
defined in this document is used (with some exceptions) as a part of
the DVB Application-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 3, line 41 skipping to change at page 3, line 5
6. Protection and Recovery Procedures . . . . . . . . . . . . . . 21 6. Protection and Recovery Procedures . . . . . . . . . . . . . . 21
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 22 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 22
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 24 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 24
6.3.1. Associating the Source and Repair Packets . . . . . . 24 6.3.1. Associating the Source and Repair Packets . . . . . . 24
6.3.2. Recovering the RTP Header and Payload . . . . . . . . 25 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 25
7. Session Description Protocol (SDP) Signaling . . . . . . . . . 26 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 26
8. Congestion Control Considerations . . . . . . . . . . . . . . 27 8. Congestion Control Considerations . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. draft-ietf-fecframe-interleaved-fec-scheme-05 . . . . . . 28 12.1. draft-ietf-fecframe-interleaved-fec-scheme-06 . . . . . . 29
12.2. draft-ietf-fecframe-interleaved-fec-scheme-04 . . . . . . 29 12.2. draft-ietf-fecframe-interleaved-fec-scheme-05 . . . . . . 29
12.3. draft-ietf-fecframe-interleaved-fec-scheme-03 . . . . . . 29 12.3. draft-ietf-fecframe-interleaved-fec-scheme-04 . . . . . . 29
12.4. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 29 12.4. draft-ietf-fecframe-interleaved-fec-scheme-03 . . . . . . 29
12.5. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 29 12.5. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 29
12.6. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 29 12.6. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 30
12.7. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . . 30 13.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
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
generated by the 1-D interleaved parity code from a source media generated by the 1-D interleaved parity code from a source media
encapsulated in RTP [RFC3550]. The resulting new RTP payload format encapsulated in RTP [RFC3550]. The resulting new RTP payload format
is registered by this document. is registered by this document.
skipping to change at page 26, line 36 skipping to change at page 26, line 36
15. Set the SSRC of the new packet to the SSRC of the source RTP 15. Set the SSRC of the new packet to the SSRC of the source RTP
stream. stream.
This procedure completely recovers both the header and payload of an This procedure completely recovers both the header and payload of an
RTP packet. RTP packet.
7. Session Description Protocol (SDP) Signaling 7. Session Description Protocol (SDP) Signaling
This section provides an SDP [RFC4566] example. The following This section provides an SDP [RFC4566] example. The following
example uses the FEC grouping semantics [RFC4756]. example uses the FEC grouping semantics [I-D.ietf-mmusic-rfc4756bis].
In this example, we have one source video stream (mid:S1) and one FEC In this example, we have one source video stream (mid:S1) and one FEC
repair stream (mid:R1). We form one FEC group with the "a=group:FEC repair stream (mid:R1). We form one FEC group with the "a=group:FEC
S1 R1" line. The source and repair streams are sent to the same port S1 R1" line. The source and repair streams are sent to the same port
on different multicast groups. The repair window is set to 200 ms. on different multicast groups. The repair window is set to 200 ms.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Interleaved Parity FEC Example s=Interleaved Parity FEC Example
t=0 0 t=0 0
skipping to change at page 28, line 9 skipping to change at page 28, line 9
levels of FEC protection needed by different receivers, it is levels of FEC protection needed by different receivers, it is
RECOMMENDED that the sender offers multiple repair flows with RECOMMENDED that the sender offers multiple repair flows with
different levels of FEC protection and the receivers join the different levels of FEC protection and the receivers join the
corresponding multicast sessions to receive the repair flow(s) that corresponding multicast sessions to receive the repair flow(s) that
is best for them. is best for them.
9. Security Considerations 9. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] and in any applicable RTP profile. The main specification [RFC3550] and in any applicable RTP profile.
security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity and The main security considerations for the RTP packet carrying the RTP
source authenticity. Confidentiality is achieved by encrypting the payload format defined within this memo are confidentiality,
RTP payload. Integrity of the RTP packets is achieved through a integrity and source authenticity. Confidentiality is achieved by
suitable cryptographic integrity protection mechanism. Such a encrypting the RTP payload. Altering the FEC packets can have a big
cryptographic system may also allow the authentication of the source impact on the reconstruction operation. An attack by changing some
of the payload. A suitable security mechanism for this RTP payload bits in the FEC packets can have a significant effect on the
format should provide confidentiality, integrity protection, and at calculation and the recovery of the source packets. For example,
least source authentication capable of determining if an RTP packet changing the length recovery field can result in the recovery of a
is from a member of the RTP session. packet that is too long. Depending on the application, it may be
helpful to perform a sanity check on the received source and FEC
packets before performing the recovery operation and to determine the
validity of the recovered packets before using them.
Integrity of the RTP packets is achieved through a suitable
cryptographic integrity protection mechanism. Such a cryptographic
system may also allow the authentication of the source of the
payload. A suitable security mechanism for this RTP payload format
should provide source authentication capable of determining if an RTP
packet is from a member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this memo may vary. It is dependent on the
application, transport and signaling protocol employed. Therefore, a application, transport and signaling protocol employed. Therefore, a
single mechanism is not sufficient, although if suitable, using the single mechanism is not sufficient, although if suitable, using the
Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. Secure Real-time Transport Protocol (SRTP) [RFC3711] is RECOMMENDED.
Other mechanisms that may be used are IPsec [RFC4301] and Transport Other mechanisms that may be used are IPsec [RFC4301] and Transport
Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may Layer Security (TLS) [RFC5246]; other alternatives may exist.
exist.
If FEC protection is applied on already encrypted source packets,
there is no need for additional encryption. However, if the source
packets are encrypted after FEC protection is applied, the FEC
packets should be cryptographically as secure as the source packets.
Failure to provide an equal level of confidentiality, integrity and
authentication to the FEC packets can compromise the source packets'
confidentiality, integrity or authentication since the FEC packets
are generated by applying XOR operation across the source packets.
10. IANA Considerations 10. IANA Considerations
New media subtypes are subject to IANA registration. For the New media subtypes are subject to IANA registration. For the
registration of the payload format and its parameters introduced in registration of the payload format and its parameters introduced in
this document, refer to Section 5. this document, refer to Section 5.
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], [RFC5109]
[SMPTE2022-1]. Thus, the author would like to thank the authors and and [SMPTE2022-1]. Thus, the author would like to thank the authors
editors of these earlier specifications. The author also thanks and 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-05 12.1. draft-ietf-fecframe-interleaved-fec-scheme-06
The following are the major changes compared to version 05:
o Comments from IETF LC have been addressed.
12.2. draft-ietf-fecframe-interleaved-fec-scheme-05
The following are the major changes compared to version 04: The following are the major changes compared to version 04:
o Comments from Vincent Roca have been addressed. o Comments from Vincent Roca have been addressed.
12.2. draft-ietf-fecframe-interleaved-fec-scheme-04 12.3. draft-ietf-fecframe-interleaved-fec-scheme-04
The following are the major changes compared to version 03: The following are the major changes compared to version 03:
o Further comments from AVT WG have been addressed. o Further comments from AVT WG have been addressed.
12.3. draft-ietf-fecframe-interleaved-fec-scheme-03 12.4. draft-ietf-fecframe-interleaved-fec-scheme-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Comments from WGLC have been addressed. o Comments from WGLC have been addressed.
12.4. draft-ietf-fecframe-interleaved-fec-scheme-02 12.5. draft-ietf-fecframe-interleaved-fec-scheme-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Some details were added regarding the use of CNAME field. o Some details were added regarding the use of CNAME field.
o Offer-Answer and Declarative Considerations sections have been o Offer-Answer and Declarative Considerations sections have been
completed. completed.
o Security Considerations section has been completed. o Security Considerations section has been completed.
12.5. draft-ietf-fecframe-interleaved-fec-scheme-01 12.6. draft-ietf-fecframe-interleaved-fec-scheme-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The timestamp field definition has changed. o The timestamp field definition has changed.
12.6. draft-ietf-fecframe-interleaved-fec-scheme-00 12.7. 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 30, line 16 skipping to change at page 30, line 39
[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.
[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-05 (work in progress),
October 2009.
[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.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
13.2. Informative References 13.2. Informative References
[I-D.ietf-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-IPTV Application-Layer
Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-01 Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-03
(work in progress), January 2009. (work in progress), September 2009.
[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.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
skipping to change at page 31, line 25 skipping to change at page 32, line 8
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Author's Address Author's Address
Ali Begen Ali Begen
Cisco Systems Cisco
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
 End of changes. 20 change blocks. 
61 lines changed or deleted 93 lines changed or added

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