idnits 2.17.1 draft-begen-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 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 416. 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == 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 (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-01 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 5 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: January 8, 2009 Digital Fountain 6 July 7, 2008 8 DVB Application-Layer Hybrid FEC Protection 9 draft-begen-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 January 8, 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. Since both of these codes have already been specified in 49 separate documents, the current document does not define the details 50 of these codes but provides the references to the respective 51 specifications. By offering a layered approach, the DVB AL-FEC 52 offers a good protection against both bursty and random packet losses 53 at a cost of decent complexity. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 59 3. DVB AL-FEC Specification . . . . . . . . . . . . . . . . . . . 5 60 3.1. Base-Layer FEC . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Enhancement-Layer FEC . . . . . . . . . . . . . . . . . . 6 62 3.3. Hybrid Decoding Procedures . . . . . . . . . . . . . . . . 6 63 4. Session Description Protocol (SDP) Signaling . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 In 2007, the Digital Video Broadcasting (DVB) consortium published a 76 technical specification [DVB-AL-FEC] 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 [DVB-AL-FEC] defines an optional protocol for 82 Application-layer FEC (AL-FEC) protection of streaming media for 83 DVB-IP services carried over RTP [RFC3550] transport. The AL-FEC 84 protocol uses two layers for protection: a base layer that is 85 produced by the 1-D interleaved parity code, and an enhancement layer 86 that is produced by the Raptor code. Whenever a receiver supports 87 AL-FEC protocol, the decoding support for the base-layer FEC is 88 mandatory while the decoding support for the enhancement-layer FEC is 89 optional. Both the interleaved parity code and the Raptor code are 90 systematic FEC codes, meaning that source packets are always sent as 91 part of the transport. 93 This document briefly explains the DVB AL-FEC protocol by providing 94 references to the two FEC schemes used as part of the AL-FEC 95 protocol. This document considers protection of single sequence RTP 96 flows only. 98 The DVB AL-FEC protocol can protect any type of source media such as 99 audio, video, text or application. The FEC data at each layer is 100 generated by an instance of the FEC Framework 101 [I-D.ietf-fecframe-framework], which is configured by the FEC 102 Framework Configuration Information. The configuration information 103 and the information contained in the Payload IDs of the source and 104 repair packets establish the exact associations and relationships 105 between the source and repair packets. This document shows how the 106 FEC Framework Configuration Information may be communicated out-of- 107 band in Session Description Protocol (SDP) [RFC4566]. 109 The FEC Framework requires the source packets to be transmitted in a 110 source flow and the repair packets to be transmitted in one or more 111 repair flows. In other words, the sender MUST NOT mix source and 112 repair packets in a single flow. At the receiver side, if all of the 113 source packets are successfully received, there is no need for FEC 114 recovery and the repair packets may be discarded. However, if there 115 are missing source packets, the repair packets can be used to recover 116 the missing information. 118 The block diagram of the encoder side for the systematic DVB AL-FEC 119 protection is sketched in Figure 1. Here, the source packets are fed 120 into the parity encoder to produce the parity repair packets. The 121 source packets may also be fed to the Raptor encoder to produce the 122 Raptor repair packets. Source packets as well as the repair packets 123 are then sent to the receiver(s) over an IP network. 125 +--------------+ 126 +--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 127 +--+ +--+ +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 128 +--------------+ 129 | Parity | -> +==+ +==+ +==+ 130 | Encoder | +==+ +==+ +==+ 131 +--------------+ 132 | Raptor | -> +~~+ +~~+ 133 | Encoder | +~~+ +~~+ 134 +--------------+ 136 Source Packet: +--+ 137 +--+ 139 Base-layer Repair Packet: +==+ 140 +==+ 142 Enhancement-layer Repair Packet: +~~+ 143 +~~+ 145 Figure 1: Block diagram for the DVB AL-FEC encoder 147 The block diagram of the decoder side for the systematic DVB AL-FEC 148 protection is sketched in Figure 2. This is a Minimum Performance 149 Decoder since the receiver only supports decoding the base-layer 150 repair packets. If there is a loss among the source packets, the 151 parity decoder attempts to recover the missing source packets by 152 using the base-layer repair packets. 154 +--------------+ 155 +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 156 +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 157 +--------------+ 158 +==+ +==+ +==+ --> | Parity | 159 +==+ +==+ +==+ | Decoder | 160 +--------------+ 162 Lost Packet: X 164 Figure 2: Block diagram for the DVB AL-FEC minimum performance 165 decoder 167 On the other hand, if the receiver supports decoding both the base- 168 layer and enhancement-layer repair packets, a combined (hybrid) 169 decoding approach is adopted to improve the recovery rate of the lost 170 packets. In this case, the decoder is called an Enhanced Decoder. 171 Section 3.3 outlines the procedures for hybrid decoding. 173 +--------------+ 174 +--+ X X +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 175 +--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 176 +--------------+ 177 +==+ +==+ +==+ --> | Parity | 178 +==+ +==+ +==+ | Decoder | 179 +--------------+ 180 +~~+ +~~+ --> | Raptor | 181 +~~+ +~~+ | Decoder | 182 +--------------+ 184 Lost Packet: X 186 Figure 3: Block diagram for the DVB AL-FEC enhanced decoder 188 2. Requirements Notation 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 3. DVB AL-FEC Specification 196 The DVB AL-FEC protocol comprises two layers of FEC protection: 1-D 197 interleaved parity FEC for the base layer and Raptor FEC for the 198 enhancement layer. 200 3.1. Base-Layer FEC 202 The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 203 to generate the repair symbols. In a group of D x L source packets, 204 the XOR operation is applied to the group of the source packets whose 205 sequence numbers are L apart from each other to generate L repair 206 packets. When used in combination with the enhancement layer, the D 207 x L block of the source packets protected by one or more FEC packets 208 SHALL be wholly contained within a single source block of the Raptor 209 code. Further details of the 1-D interleaved parity code are 210 provided in [I-D.begen-fecframe-interleaved-fec-scheme]. 212 3.2. Enhancement-Layer FEC 214 The Raptor code is a fountain code where as many encoding symbols as 215 needed can be generated by the encoder on-the-fly from a source data. 216 Due to the fountain property of the Raptor code, multiple enhancement 217 layers may also be specified. 219 The details of the Raptor code are provided in 220 [I-D.watson-fecframe-raptor]. The performances of both the 1-D 221 interleaved parity code and Raptor code have been examined in detail 222 in [DVB-A115]. 224 3.3. Hybrid Decoding Procedures 226 The receivers that support receiving and decoding both the base and 227 enhancement-layer FEC perform hybrid decoding to improve the repair 228 performance. The following step may be followed to perform hybrid 229 decoding: 231 1. Base-layer (Parity) Decoding: In this step, the repair packets 232 that are encoded by the parity encoder are processed as usual to 233 repair as many missing source packets as possible. 235 2. Enhancement-layer (Raptor) Decoding: If there are still missing 236 source packets after the first step, the repair packets that are 237 Raptor encoded are processed with the source packets already 238 received and the source packets that are recovered in the first 239 step. 241 3. Hybrid Decoding: If there are still missing source packets after 242 the second step, the unprocessed base-layer (parity) repair 243 packets are converted to a form in which they can be added to the 244 Raptor decoding process. With this additional information, 245 Raptor decoding may potentially recover any remaining missing 246 source packet. 248 The procedure that should be followed to benefit from the base-layer 249 repair packets in the Raptor decoding process is explained in detail 250 in Section E5.2 of [DVB-AL-FEC]. 252 4. Session Description Protocol (SDP) Signaling 254 This section provides an SDP [RFC4566] example. This example uses 255 the SDP elements for FEC Framework, which were introduced in 256 [I-D.ietf-fecframe-sdp-elements], and the FEC grouping semantics 257 [RFC4756]. 259 Editor's note: No FEC Encoding IDs have been registered with IANA 260 for the 1-D interleaved parity FEC scheme and Raptor FEC scheme. For 261 illustrative purposes, in the example below, FEC Encoding IDs of 10 262 and 11 will respectively be used. 264 In this example, we have one source video stream (mid:S1), one FEC 265 repair stream (mid:R1) that is produced by the 1-D interleaved parity 266 FEC scheme as well as another FEC repair stream (mid:R2) that is 267 produced by the Raptor FEC scheme. We form one FEC group with the 268 "a=group:FEC S1 R1 R2" line. The source and repair streams are sent 269 to the same port on different multicast groups. The repair window is 270 set to 200 ms. 272 v=0 273 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 274 s=DVB AL-FEC Example 275 t=0 0 276 a=group:FEC S1 R1 R2 277 m=video 30000 RTP/AVP 100 278 c=IN IP4 224.1.1.1/127 279 a=rtpmap:100 MP2T/90000 280 a=fec-source-flow: id=0 281 a=mid:S1 282 m=application 30000 RTP/AVP 110 283 c=IN IP4 224.1.2.1/127 284 a=rtpmap:110 1d-interleaved-parityfec/90000 285 a=fec-repair-flow: encoding-id=10; ss-fssi=L:5 D:10 286 a=repair-window: 200 287 a=mid:R1 288 m=application 30000 RTP/AVP 111 289 c=IN IP4 224.1.3.1/127 290 a=rtpmap:111 raptor-fec/90000 291 a=fec-repair-flow: encoding-id=11; ss-fssi=qwe123 292 a=repair-window: 200 293 a=mid:R2 295 5. Security Considerations 297 The are no security considerations in this document. For the general 298 security considerations related to the use of FEC, refer to 299 [I-D.ietf-fecframe-framework]. 301 6. IANA Considerations 303 The are no IANA considerations in this document. 305 7. Acknowledgments 307 This document is largely based on [DVB-AL-FEC]. Thus, the authors 308 would like to thank the editors of [DVB-AL-FEC]. 310 8. References 312 8.1. Normative References 314 [I-D.ietf-fecframe-framework] 315 Watson, M., "Forward Error Correction (FEC) Framework", 316 draft-ietf-fecframe-framework-01 (work in progress), 317 November 2007. 319 [I-D.ietf-fecframe-sdp-elements] 320 Begen, A., "SDP Elements for FEC Framework", 321 draft-ietf-fecframe-sdp-elements-00 (work in progress), 322 February 2008. 324 [I-D.begen-fecframe-interleaved-fec-scheme] 325 Begen, A., "1-D Interleaved Parity FEC Scheme for FEC 326 Framework", draft-begen-fecframe-interleaved-fec-scheme-00 327 (work in progress), July 2008. 329 [I-D.watson-fecframe-raptor] 330 Watson, M., "Raptor FEC Schemes for FECFRAME", 331 draft-watson-fecframe-raptor-00 (work in progress), 332 July 2008. 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 338 Jacobson, "RTP: A Transport Protocol for Real-Time 339 Applications", STD 64, RFC 3550, July 2003. 341 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 342 Description Protocol", RFC 4566, July 2006. 344 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 345 Session Description Protocol", RFC 4756, November 2006. 347 8.2. Informative References 349 [DVB-AL-FEC] 350 DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1), 351 "Transport of MPEG 2 Transport Stream (TS) Based DVB 352 Services over IP Based Networks", March 2007. 354 [DVB-A115] 355 Available at: http://www.dvb.org/technology/standards/ 356 a115.tm3783.AL-FEC_Evaluation.pdf, "DVB Application Layer 357 FEC Evaluations (DVB Document A115)", May 2007. 359 Authors' Addresses 361 Ali Begen 362 Cisco Systems 363 170 West Tasman Drive 364 San Jose, CA 95134 365 USA 367 Email: abegen@cisco.com 369 Thomas Stockhammer 370 Digital Fountain 371 39141 Civic Center Drive 372 Suite 300 373 Fremont, CA 94538 374 USA 376 Email: stockhammer@digitalfountain.com 378 Full Copyright Statement 380 Copyright (C) The IETF Trust (2008). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 389 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 390 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Intellectual Property 396 The IETF takes no position regarding the validity or scope of any 397 Intellectual Property Rights or other rights that might be claimed to 398 pertain to the implementation or use of the technology described in 399 this document or the extent to which any license under such rights 400 might or might not be available; nor does it represent that it has 401 made any independent effort to identify any such rights. Information 402 on the procedures with respect to rights in RFC documents can be 403 found in BCP 78 and BCP 79. 405 Copies of IPR disclosures made to the IETF Secretariat and any 406 assurances of licenses to be made available, or the result of an 407 attempt made to obtain a general license or permission for the use of 408 such proprietary rights by implementers or users of this 409 specification can be obtained from the IETF on-line IPR repository at 410 http://www.ietf.org/ipr. 412 The IETF invites any interested party to bring to its attention any 413 copyrights, patents or patent applications, or other proprietary 414 rights that may cover technology that may be required to implement 415 this standard. Please address the information to the IETF at 416 ietf-ipr@ietf.org. 418 Acknowledgment 420 Funding for the RFC Editor function is provided by the IETF 421 Administrative Support Activity (IASA).