idnits 2.17.1 draft-ietf-fecframe-dvb-al-fec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2008) is 5713 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Informational T. Stockhammer 5 Expires: March 2, 2009 Digital Fountain 6 August 29, 2008 8 DVB Application-Layer Hybrid FEC Protection 9 draft-ietf-fecframe-dvb-al-fec-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 2, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes the Application-layer Forward Error 43 Correction (FEC) protocol that was developed by the Digital Video 44 Broadcasting (DVB) consortium for the protection of media streams 45 over IP networks. The DVB AL-FEC protocol uses two layers for FEC 46 protection. The first (base) layer is based on the 1-D interleaved 47 parity code. The second (enhancement) layer is based on the Raptor 48 code. By offering a layered approach, the DVB AL-FEC offers a good 49 protection against both bursty and random packet losses at a cost of 50 decent complexity. The 1-D interleaved parity code and Raptor code 51 have already been specified in separate documents and the current 52 document normatively references these specifications. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 58 3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5 59 3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 5 61 3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 6 62 4. Session Description Protocol (SDP) Signaling . . . . . . . . . 6 63 5. Status of DVB AL-FEC Specification . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 In 2007, the Digital Video Broadcasting (DVB) consortium published a 76 technical specification [ETSI-TS-102-034] through European 77 Telecommunications Standards Institute (ETSI). This specification 78 covers several areas related to the transmission of MPEG2 transport 79 stream-based services over IP networks. 81 The Annex E of [ETSI-TS-102-034] defines an optional protocol for 82 Application-layer Forward Error Correction (AL-FEC) to protect the 83 streaming media for DVB-IP services carried over RTP [RFC3550] 84 transport. The AL-FEC protocol uses two layers for protection: a 85 base layer that is produced by the 1-D interleaved parity code, and 86 an enhancement layer that is produced by the Raptor code. Whenever a 87 receiver supports AL-FEC protocol, the decoding support for the base- 88 layer FEC is mandatory while the decoding support for the 89 enhancement-layer FEC is optional. Both the interleaved parity code 90 and the Raptor code are systematic FEC codes, meaning that source 91 packets are always sent as part of the transport. 93 This document briefly explains the DVB AL-FEC protocol by providing 94 references to the two FEC codes used as part of the AL-FEC protocol. 95 This document considers protection of single-sequence RTP flows only. 96 The DVB AL-FEC protocol can protect any type of source media such as 97 audio, video, text or application. The FEC data at each layer is 98 generated based on some configuration information, which also 99 determines the exact associations and relationships between the 100 source and repair packets. This document shows this configuration 101 may be communicated out-of-band in Session Description Protocol (SDP) 102 [RFC4566]. 104 In DVB AL-FEC, the source packets are carried in the source RTP 105 stream and the generated FEC repair packets at each layer are carried 106 in separate RTP streams. At the receiver side, if all of the source 107 packets are successfully received, there is no need for FEC recovery 108 and the repair packets may be discarded. However, if there are 109 missing source packets, the repair packets can be used to recover the 110 missing information. 112 The block diagram of the encoder side for the systematic DVB AL-FEC 113 protection is sketched in Figure 1. Here, the source packets are fed 114 into the parity encoder to produce the parity repair packets. The 115 source packets may also be fed to the Raptor encoder to produce the 116 Raptor repair packets. Source packets as well as the repair packets 117 are then sent to the receiver(s) over an IP network. 119 +--------------+ 120 +--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 121 +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 122 +--------------+ 123 | Parity | -> +==+ +==+ +==+ 124 | Encoder | +==+ +==+ +==+ 125 +--------------+ 126 | Raptor | -> +~~+ +~~+ 127 | Encoder | +~~+ +~~+ 128 +--------------+ 130 Source Packet: +--+ 131 +--+ 133 Base-layer Repair Packet: +==+ 134 +==+ 136 Enhancement-layer Repair Packet: +~~+ 137 +~~+ 139 Figure 1: Block diagram for the DVB AL-FEC encoder 141 The block diagram of the decoder side for the systematic DVB AL-FEC 142 protection is sketched in Figure 2. This is a Minimum Performance 143 Decoder since the receiver only supports decoding the base-layer 144 repair packets. If there is a loss among the source packets, the 145 parity decoder attempts to recover the missing source packets by 146 using the base-layer repair packets. 148 +--------------+ 149 +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 150 +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 151 +--------------+ 152 +==+ +==+ +==+ --> | Parity | 153 +==+ +==+ +==+ | Decoder | 154 +--------------+ 156 Lost Packet: X 158 Figure 2: Block diagram for the DVB AL-FEC minimum performance 159 decoder 161 On the other hand, if the receiver supports decoding both the base- 162 layer and enhancement-layer repair packets, a combined (hybrid) 163 decoding approach is employed to improve the recovery rate of the 164 lost packets. In this case, the decoder is called an Enhanced 165 Decoder. Section 3.3 outlines the procedures for hybrid decoding. 167 +--------------+ 168 +--+ X X X --> | Systematic | -> +--+ +--+ +--+ +--+ 169 +--+ |FEC Protection| +--+ +--+ +--+ +--+ 170 +--------------+ 171 +==+ +==+ +==+ --> | Parity | 172 +==+ +==+ +==+ | Decoder | 173 +--------------+ 174 +~~+ +~~+ --> | Raptor | 175 +~~+ +~~+ | Decoder | 176 +--------------+ 178 Lost Packet: X 180 Figure 3: Block diagram for the DVB AL-FEC enhanced decoder 182 2. Requirements Notation 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. DVB AL-FEC Specification 190 The DVB AL-FEC protocol comprises two layers of FEC protection: 1-D 191 interleaved parity FEC for the base layer and Raptor FEC for the 192 enhancement layer. 194 3.1. Base-Layer FEC 196 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 197 to generate the repair symbols. In a group of D x L source packets, 198 the XOR operation is applied to the group of the source packets whose 199 sequence numbers are L apart from each other to generate L repair 200 packets. When used in combination with the enhancement layer, the D 201 x L block of the source packets protected by one or more FEC packets 202 SHALL be wholly contained within a single source block of the Raptor 203 code. Further details of the 1-D interleaved parity code are 204 provided in [I-D.begen-fecframe-interleaved-fec-scheme]. 206 3.2. Enhancement-Layer FEC 208 The Raptor code is a fountain code where as many encoding symbols as 209 needed can be generated by the encoder on-the-fly from a source data. 210 Due to the fountain property of the Raptor code, multiple enhancement 211 layers may also be specified, if needed. 213 The details of the Raptor code are provided in 214 [I-D.watson-fecframe-raptor]. The performances of both the 1-D 215 interleaved parity code and Raptor code have been examined in detail 216 in [DVB-A115]. 218 3.3. Hybrid Decoding Procedures 220 The receivers that support receiving and decoding both the base and 221 enhancement-layer FEC perform hybrid decoding to improve the repair 222 performance. The following steps may be followed to perform hybrid 223 decoding: 225 1. Base-layer (Parity) Decoding: In this step, the repair packets 226 that are encoded by the parity encoder are processed as usual to 227 repair as many missing source packets as possible. 229 2. Enhancement-layer (Raptor) Decoding: If there are still missing 230 source packets after the first step, the repair packets that are 231 Raptor encoded are processed with the source packets already 232 received and the source packets that are recovered in the first 233 step. 235 3. Hybrid Decoding: If there are still missing source packets after 236 the second step, the unprocessed base-layer (parity) repair 237 packets are converted to a form in which they can be added to the 238 Raptor decoding process. With this additional information, 239 Raptor decoding may potentially recover any remaining missing 240 source packet. 242 The procedure that should be followed to benefit from the base-layer 243 repair packets in the Raptor decoding process is explained in detail 244 in Section E.5.2 of [ETSI-TS-102-034]. 246 4. Session Description Protocol (SDP) Signaling 248 This section provides an SDP [RFC4566] example. This example uses 249 the FEC grouping semantics [RFC4756]. 251 In this example, we have one source video stream (mid:S1), one FEC 252 repair stream (mid:R1) that is produced by the 1-D interleaved parity 253 FEC scheme as well as another FEC repair stream (mid:R2) that is 254 produced by the Raptor FEC scheme. We form one FEC group with the 255 "a=group:FEC S1 R1 R2" line. The source and repair streams are sent 256 to the same port on different multicast groups. The repair window is 257 set to 200 ms. 259 Editor's note: The payload-format-specific parameters have not been 260 defined for Raptor FEC yet. Once they are defined, the "a=fmtp" for 261 the second repair stream will be updated accordingly. 263 v=0 264 o=ali 1122334455 1122334466 IN IP4 fec.example.com 265 s=DVB AL-FEC Example 266 t=0 0 267 a=group:FEC S1 R1 R2 268 m=video 30000 RTP/AVP 100 269 c=IN IP4 224.1.1.1/127 270 a=rtpmap:100 MP2T/90000 271 a=mid:S1 272 m=application 30000 RTP/AVP 110 273 c=IN IP4 224.1.2.1/127 274 a=rtpmap:110 1d-interleaved-parityfec/90000 275 a=fmtp:110 L:5; D:10; repair-window: 200000 276 a=mid:R1 277 m=application 30000 RTP/AVP 111 278 c=IN IP4 224.1.3.1/127 279 a=rtpmap:111 raptor-fec/90000 280 a=fmtp:111 ss-fssi=qwe123; repair-window: 200000 281 a=mid:R2 283 5. Status of DVB AL-FEC Specification 285 At the time of writing this document, there were scheduled updates in 286 the DVB AL-FEC specification. Some parts of these updates will be 287 based on the [I-D.begen-fecframe-interleaved-fec-scheme] and 288 [I-D.watson-fecframe-raptor]. Further updates (if necessary) in the 289 AL-FEC specification may be published by DVB. 291 6. Security Considerations 293 The are no security considerations in this document. 295 7. IANA Considerations 297 The are no IANA considerations in this document. 299 8. Acknowledgments 301 This document is based on [ETSI-TS-102-034]. Thus, the authors would 302 like to thank the editors of [ETSI-TS-102-034]. 304 9. References 306 9.1. Normative References 308 [I-D.begen-fecframe-interleaved-fec-scheme] 309 Begen, A., "1-D Interleaved Parity FEC Scheme for FEC 310 Framework", draft-begen-fecframe-interleaved-fec-scheme-00 311 (work in progress), July 2008. 313 [I-D.watson-fecframe-raptor] 314 Watson, M., "Raptor FEC Schemes for FECFRAME", 315 draft-watson-fecframe-raptor-00 (work in progress), 316 July 2008. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 322 Jacobson, "RTP: A Transport Protocol for Real-Time 323 Applications", STD 64, RFC 3550, July 2003. 325 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 326 Description Protocol", RFC 4566, July 2006. 328 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 329 Session Description Protocol", RFC 4756, November 2006. 331 9.2. Informative References 333 [ETSI-TS-102-034] 334 DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1), 335 "Transport of MPEG 2 Transport Stream (TS) Based DVB 336 Services over IP Based Networks", March 2007. 338 [DVB-A115] 339 Available at: http://www.dvb.org/technology/standards/ 340 a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer 341 FEC Evaluations (DVB Document A115)", May 2007. 343 Authors' Addresses 345 Ali Begen 346 Cisco Systems 347 170 West Tasman Drive 348 San Jose, CA 95134 349 USA 351 Email: abegen@cisco.com 353 Thomas Stockhammer 354 Digital Fountain 355 39141 Civic Center Drive 356 Suite 300 357 Fremont, CA 94538 358 USA 360 Email: stockhammer@digitalfountain.com 362 Full Copyright Statement 364 Copyright (C) The IETF Trust (2008). 366 This document is subject to the rights, licenses and restrictions 367 contained in BCP 78, and except as set forth therein, the authors 368 retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Intellectual Property 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org. 402 Acknowledgment 404 Funding for the RFC Editor function is provided by the IETF 405 Administrative Support Activity (IASA).